Top Ten Reasons Why Projects Fail – Reason #1

Projects fail because scope is out of control. Scope is defined by the Project Management Institute (PMI) as “The sum of the products, services, and results to be provided as a project.” So that’s a pretty simple definition, right? It’s everything that you are going to do on the project. The unspoken corollary to this is that everything that is NOT the sum of the products, services, and results is out of scope. So if out of scope, you’re not going to do it. At least not at this time on this project.

So what’s so hard about sticking to the scope? Should be easy. First you define it. And how do you do that? Well, briefly, you  (or your sponsor) should develop a charter, just a couple of pages long, which provides summary details of the project, enough to get approval from management. Once you have that, you (and your team) create your scope statement (a written summary of what you are going to do) and your Work Breakdown Structure (a hierarchical, visual display of your deliverables). Once you have those two items – and everybody agrees on the scope – you create your schedule and start to execute. (There are other things you’d create such as a risk register and requirements documents. But for the sake of this discussion, let’s assume you’ve done them).

Now you, as the PM, start managing the team and executing the project. All is well for, say, the first two months of your 18-month project. Then one day, someone from, let’s say, marketing runs over to you and says, “Stop the presses. Customer now needs a new widget added to the product.” And so now you have a choice. Do you a) ignore him, B) make the change or C) present it to your change control board (CCB) for consideration? Don’t have a CCB you say? Well, you should. And it should be comprised of key stakeholders such as sponsor, exec VP, PM, etc. They should then review the change and decide to accept or reject it. If rejected, you then advise the stakeholders. If accepted, project manager should issue a new schedule, budget, risk register, WBS, scope statement and any other artifact that he/she deems necessary.

This seems like an amazingly simple solution. But does this happen in the average company I consult to or where I teach? Sadly, no. What happens is that the aforementioned marketing (or sales, senior management, customer – pick one) person yells loudly and when he or she does, the PM scrambles to “make it happen.” (BTW, this is not meant to blame the senior managers. They’re just doing their job). But the project manager’s fatal flaw – and this is called scope creep – is that he does not issue any new project artifacts. And so everybody continues working to the same now impossible-to-meet schedule. And then the project fails, blame is ascribed and everybody scrambles for cover.

Now, by comparison, imagine an architect building a house. He knows exactly what the customer wants.  And so, while building the house, the customer comes along and says, “I now want three bedrooms instead of two.” If the architect is able to make the change, will he adhere to the same schedule and budget? Of course not. It’s ludicrous. But this is what we do all the time in projects. And if you want to prevent it, you must establish for every project a CCB and it must have the weight of the organization behind it. You must be willing to push back on customer/senior management/sponsor and tell them that you’re doing it not to be difficult but for the ultimate good of the project.

I know it’s very hard to push back. Managing projects for your company is your job and you don’t want to jeopardize it. And the senior managers hold all the cards. But still, it must be done. Because at the end of the day, you’re the one who’s going to be called on the carpet when the thing grows out of control.

Comments are closed.