There are quite a few bad projects out there
I’ve seen quite a few projects in my career. Some were executed well, but most of them failed to achieve the initial objectives and were subject to course corrections along the way.
Examining them more closely, I noticed that almost without exception, the projects that failed were badly defined. Badly defined projects lead frequently to bad results. Bad results translates to the non-achievement of the initial objectives. But what causes bad project definitions, and how can we avoid them?
Project quality is a function of to how project owners deal with constraints
Every project is logically confronted with constraints. You cannot have unlimited money, nor an unlimited supply of people to help you who can pretty much do anything you throw at them. Rather, you usually end up with a rag-tag group of people, some young, some old, some enthousiast, some who would rather not want to be there. Some will be capable, some will have been put there by their respective department heads in order to get rid of them.
As to money, even if there were not a crisis out there, means would be limited. You are in permanent competition with others for the limited resources your organization has available.
Oh, and finally, you don’t have a hundred years to do the work. Rather, it needs to be finished now. Make that yesterday. Because we need it now.
In other words, the constraints you will be facing are constraints of means, capabilities and time:
- Means are either people – as in full time equivalents – or budgets
- Capabilities refer to what the available people can and cannot do
- Time refers to the available time slots in which to reach certain objectives.
You may call that unreasonable. But it often is all in a day’s work for a project manager. And a good project manager will help the project owner in making the optimal decisions about the project in light of the constraints. Because of the existence of constraints, choices have to be made.
A good project manager can influence and even determine the quality of the final result
To me, the quality of those choices is a very good reflection of the quality of the project manager responsible for developing the project specs and executing it. Note I start with the project specs. Quite often, a project manager is brought in after the project has been defined. Once a project definition has been agreed upon by the stakeholders involved, any adaptation of the final deliverable, for whatever reason, will be seen as a loss. Ideally, as a project manager, you become involved as soon as possible.
The magic equation
A partner at Andersen Consulting (now Accenture) one explained the following magic equation to me:
S = D/E
or
Satisfaction = Delivery / Expectations
It’s an obvious equation, but a very powerful one indeed. For example, the higher the initial expectations, the better your delivery needs to be in order to reach the required or wanted satisfaction.
Now, let’s apply this to project management under constrained conditions: your constraints will play mainly on your delivery. Hence, in order to manage your satisfaction level, or, in laymen’s terms, in order to keep your client happy, you will need to manage his expectations. And how do you manage his expectations? By ensuring that you communicate very clearly on what you aim to achieve. And now we’re going deeper and deeper into that rabbit hole. Because in order to be able to state clearly what you aim to achieve, you need to have a very good idea on what you want to achieve and how possible that is under the given constrained conditions.
Choices under constrained conditions need to lead to optimal achievement of vision
This is where the vision of a good project manager and a good project owner come into play. The choices made under constrained conditions need to lead to the optimal achievement of that vision. If the vision is clear and owned/shared by all stakeholders, and the project manager is competent, the choices will be consistent.
The quality of a project is then a reflection of that vision as “owned” by the project owners, and managed by a project manager, where choices are made within the chalk lines of the constraints. If the vision is strong, choices will be made and certain stuff will not get done. Because it is not achievable within the constraints. On the contrary, if the project manager is not very good and cannot convince the project owner or the stakeholders, the choices will be all over the place in order to placate the different stakeholders involved.
Chosing of or chosing against something
Clear vision leads to results. If the vision is muddy, offers on results are made across the board, often linear and without any consistency. This is the difference between chosing for something rather than chosing against something.
Further reading
I would really like to refer you to this piece by Matt Gemmell, who wrote about this in the context of products as opposed to projects which I discuss here. The same concepts hold. Enjoy Matt’s writing, he’s on fire lately.
Exploring The Black Box 