In developing systems, the denoument often comes at the very beginning of the project. The projects Success or Failure is written right in the feasibility and requirements stage. And if Failure is chosen, then the drama and exact level of pain to be inflicted is played out, like Japanese Kabuki theater, in a series of ritualized acts and stages. Of course we have all seen the cartoons on systems development=> what production wanted: a simple rope and tire swing; what the consultants planned: an elaborate miniature ferris wheel; what IT could deliver: a hopeless Rube Goldberg machine; and what was finally delivered: some parts and rope scattered all over the ground.
Let me propose here that those scenarios can be identified right up front in the Feasibility and Requirements stage because major stakeholders, despite protestations and apparent admonitions to the contrary, chose Failure right from the outset. It is the business of 3 parties to ferret out the pre-doomed projects and either perform radical surgery or move on to other projects where the stars are aligned better. We call them the 3 Project Musketeers; but even they may be Choosing Failure.
Now Choosing Failure smacks of sabotage and organizational betrayal, and such blatant malfeasance simply is not tolerated in most organizations. Or is it? These Choosings of Failure are not necessarily the schemings of Machiavellians carefully calculating which projects to scuttle and which to allow to succeed – though such plays and players certainly have to be accounted for. Rather they may very will be the defensive acts of a department leader already swamped with shaky prospects who needs to delay a project which will inflict a great deal of change and chaos on his/her already extended to the limits staff. Or it may be the act of defiance of some critical stakeholders who were left out of project formulation who decide “well if the project is going to succeed its going to be on our high risk inducing terms”.
And this is the crucial ingredient for Choosing Failure – the key assassinating parties never choose a blatant poison pill but rather a set of stated and unstated goals and constraints that they know will not alone cause the project to fail; but combined with other stakeholders demands and requirements will put the project in great risk. And the goals and constraints can be ambivalent or to-be-revealed at a later date. Such goals and constraints will accomplish the following:
a)if the goals and constraints are miraculously met through Herculean efforts of the team and project manager, they can help in the celebration and take credit for defining the winning formula. Meanwhile their own private goals at least have been partly achieved;
b)if the project starts to wobble or threaten their status quo too greatly, they can release a set of understated constraints and “emerging” goals that will either push the project in the direction they want or scuttle it. Yes, high risk chicken on the job;
c)if the project is deemed untenable from the outset; these are a series of constraints and cross purpose goals that alone will not scuttle the project but in combination with other stakeholders or likely external events will bring the project down.
As noted previously, it is the goal of three parties to discover these Choosings of Failure and to act accordingly.
Three Musketeers of Projects
We call these defenders of projects, the three musketeers because their number one goal is to shepherd a project to successful conclusion. The three project musketeers are 1)the championing executive; 2)the stakholder(s) with the greatest total resource commitment in budget and people to not just the development but also ongoing operation of the project; and 3)the project leader.
It is the project leaders point of view that we argue for in the remainder of this piece.
Immediate signs of Choosing Failure. The championing executive is absent or stays resolutely under-informed, mildly interested at best and/or erraticly watchful of the project. Standish Group, who have a project stewardship consulting practice, have identified the lack of an executive champion as one of the key causes of project failure. Please note this project stakeholders and project leader – your chance of project success is reduced by at least one third without an executive champion. Do not underestimate the importance of the role of an informed and committed decider of “whats best for the organization”.
Another sign of Choosing Failure. The project paying stakeholders cannot commit budget but more importantly committ key personnel to the project on an ongoing basis. During the feasibility and the requirements stages, they and/or their support staff are either a revolving door of bodies or just simply nobody – they fail to show. This to the championing executive and the project leader should turn on the loudest possible “Danger, Danger” klaxons. If the Executive Champion fails to bring the stakeholders on board, the project leader should consider Scuttling the Project(see below).
Sure signs of Choosing Failure. During the Feasibility stage clear measures of project success cannot be agreed upon or worse are not even discussed. Signs of serious problems – there is no TCO-Total Cost of Ownerhip study or ROI_return on invest done for the project. parties cannot agree on the nature and priorities of the goals for the project. Or parties cannot agree on or do not discuss the constraints and performance measure of the project. Very specific targets measures are not contemplated: the project will be delivered in this time frame; delays beyond which incur these costs and penalties. The functionality delivered will enable these cost savings or specific performance improvements. If the project cannot deliver this level of service or these reductions in cost – it has reached a crossover or tipping point where all parties agree to consider scuttling or redesigning the project. If these type of hard headed and frank discussions are not taking place during feasibility, then the 3 project musketeers have to ask themselves – when are hese discussions going to take place, after project failure ?
Note the importance of feasiblity studies. This is where ambiguity and ambivalence and mixed motives get flushed out with careful delineation of projects goals and constraint plus the measure of them. Machiavellians and saboteurs can ill afford such clarity and so they will resist such definitions saying time, constraints, and/or changing environmental dynamics have not allowed them to be specific but if you will give them ridiculous time and resources they might be able to come up “with something”.
It is time to flush them out. So give these players a risk assesment task. They are to go away along with a second or third trusted parties and do a quick one day “independent”(no cross talking) risk assessment of this particular phase of the project or measure of success. In effect they are entrusted with furthering the success or failure of the project. Their analysis compared with trusted results will reveal a lot of friend or foe tendencies. The executive champion and/or stakeholders ability to act for the project in these circumstances reveals true musketeers or not.
More subtle signs of Choosing Failure. Scott Ambler in his column in the October 2005 issue of Software Development Magazine describes some of the techniques used to elicit true collaborative requirements. Scott is assuming that all parties have passed the Feasibility phase as committed to the project. Here is how to tell if some players have had a change of heart or have successfully disguised their choice of Failure. In JAD or Focus groups, they fail to show, come ill-prepared, or have uninitiated underlings “take notes”. They keep participation to a minimum and when asked for definitive answers, they defer to others and dont really say what they are for or against. They consistently duck work assignments or take them on and then produce low grade results and often late. Finally, they generally oppose any early testing, problem discovery and prototyping. Actions that will test project feasibility, especially in their domain, are studiously avoided. These tests may be productive and/or reveal the nature and depth of their true opposition to the project. Again, the way to flush out these clandestine saboteurs is to get them to testify to their commitment to the project before their bosses and/or key members of the project team. This unfortunately is like Microsoft Security – it does not prevent the breech of trust, but it surely identifies the culprit in the aftermath. Yes, in the case of suicide bombers, this is highly ineffective.
For many projects Choosing Failure comes early in the Feasibility and Requirement stage. Given that IT projects often have massive and subtle Management of Change issues – information and control associated with systems cut to the heart of responsibility, advancements and rewards in all orgainizations. So it should be no surprise to the three musketeers who work to guarantess project success, that during the Feasibility andRequirements stages, Project Friends will be revealed and Foes will be working to literally under mine (i.e. stealth mine the project with ambivalent and understated goals and constraints that they can quietly detonate for maximum self serving effect). But the project leader has to be conscious of the fact that his other musketeers may very well be machiavellians as well and Choosing Failure.
This is the most dangerous of cirumstances. The project leader may have to choose Scuttling the Project. Any ships captain worth his salt will tell you that is best to go down with the ship in port(feasibility and requirements stages) then to do so on the high seas (hopeless late and/or dysfunctional on delivery). Yes, scuttling is very risky and messy business. being fired or demoted may be part of the consequences. But there is a silver lining, at a PMA conference I overheard a bunch of project leaders chatting, and it was a badge of pride to have a scuttled project on their resumes.
(c)JBSurveyer 2005 – This piece is dedicated to Robin at Business Objects who Chose Failure illuminatingly.