In these difficult economic times, where can I cut corners in my project (and still succeed)?

In the classic three-element formula for projects, you can play with any two of scope, time, and resources.  If you are trying to reduce resources (for economic reasons), and your world will not let you take forever to finish, then you must reduce scope.  How do you figure out the minimum levels that will still lead to success?

 

Here are some thoughts to guide those decisions, based upon the dimensions of project health known as the Seven Keys To Success.  If a contemplated reduction in scope would jeopardize one or more of these dimensions of project health, then in my view cutting corners in that fashion would be ill-advised.

 

And there are two fundamentally different ways to cut scope:

 

Reduction of features and functions

 

This can be a highly successful way to reduce costs (and also speed up the schedule, and perhaps even reduce risk).  The health dimension to monitor is Business Benefits Will Be Realized.  If the contemplated reductions will not too adversely impact the business case (and the reductions can be added to a later version, perhaps) then cutting corners this way can make a lot of sense.  One caution:  the judge of this should be the business sponsor, not the Project Manager or the IT function.

 

Cut tasks in the methodology or radically reduce their level of effort 

 

This is the second, and potentially more insidious, approach to reducing scope.  Remember that a methodology is supposed to provide a reliable answer to my two favorite questions: “How will we know when we are done?” and “How will we know if we have a good answer/outcome, not just any answer/outcome?”  (On these two questions hang all the methods, the controls, and the quality.)

 

So what might we be tempted to cut? 

 

IT history is replete with ideas like “Rapid Application Development” and “Agile Development”, often followed by lots of project failures, because practitioners of these approaches tried to cut too many corners in the early stages of understanding requirements.  You can’t reliably manage the twin health dimensions of Business Benefits Will Be Realized and Work And Schedule Are Predictable if you follow a flawed method. 

 

Here’s another temptation:  let’s cut all the “soft” activities like communications, change management, and perhaps even training.   After all, they don’t contribute directly to the production of a working solution.  Perhaps they are unnecessary.  Perhaps, if you have fewer stakeholders/users than you have programmers.  Perhaps, if there is no apprehension among anyone about how their world might change.  Perhaps, if the new functionality is so trivial and obvious that anyone will come up to speed instantly. 

 

The first and most critical dimension of project health is Stakeholders Are Committed.  And project managers cannot merely wish this to be the case.  Even the Business Sponsor (the most important stakeholder) cannot dictate a healthy level of commitment from all the other stakeholders.  It does in fact take some communications, some change management activities, and some training.  Be very careful about what corners get cut here.

 

The bottom line

 

Cutting corners judiciously can help us get through these tough times.  Just be sure that you don’t sacrifice good health and success for the sake of (apparent) expediency.