Velocity Part 5.1. Elevating Technical Maturity; Resource Availability Issues

Perfection of means and confusion of goals seem — in my opinion — to characterize our age.
Albert Einstein

In my last blog entry, I started discussing how to elevate the capacity to change constraint through the management of resource availability. Last time, I referred you directly to the words of Goldratt and his staff on the Theory of Constraints (TOC), as they apply it to managing projects, namely his business novel, Critical Chain, and a summary of the principles it contains [i].

For Goldratt, resource availability is one of the main issues in managing projects successfully. As discussed in a previous blog entry[ii], I think we can group resource availability issues in four categories:

• availability of economic resources in the quantity and at the time required (budgets, money and proper cash flows);
• availability of material resources of the proper nature, and in the quantity and at the time required (materiel, space, equipment, informational/TI resources, tools, etc.);
• availability of the required qualified performing/affected humans (human resources issues)
  • in the quantity and at the time required, as well as
  • at the necessary level of readiness when required
• finally, availability of time in sufficient quantity to realise what is necessary in the timeframe that is desired and/or has been set for the anticipated change to be implemented and for its benefits to materialise. 

All these resource availability issues are linked to the realisation strategy of the project at hand, namely answering the questions:

• Which specific economic, material and human resources are required?
• When, in which logical sequence, and for how long will these resources need to be made available?
• How will they be used?
• By whom will they be transformed into the necessary deliverables? …as well as
• How will those answers change as the project evolve and how these changes will be tracked and taken into account?

More often than not, in many projects, those questions are answered without properly sharing information on the why of the project, and on the specific what that has to be done as the situation evolves. Such projects often end up not having, over time, the proper resources required to succeed. The results presented in studies like the Chaos Report[iii] are quite eloquent and reflect this problem:

On the success side, the average is only 16.2% for software projects that are completed on time and on budget. In larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions.

I submit here that such a situation is not caused by the fact that we do not have sufficient resources to make those projects, but by the fact that they were ill-defined to start with. Even if and when the resources required are sufficient, they are being wasted through unshared, ill-fated deployment plans.

I once asked participating project managers in one of my workshops, how many of them believed that they were working on a project with unrealistic timeframe and/or insufficient resources. All of them (there were 15) raised their hands. This cannot be possible. They were all coming from the same huge multinational organisation, a world leader in its field of business. The problem was that these 15 project managers did not have the same perceptions that their project sponsors/clients had about what was the nature of the projects at hand and, then, about what were the required resources necessary over time to succeed in delivering anticipated benefits. 

The first condition a project manager has to meet, in order to elevate resource availability constraints on the project s/he has to deliver, is to ensure everyone contributing on this project sees the same project, understands the same project, values the same project …and desires the same project outcome. This condition must be met not only at the beginning of the endeavour, but every single day of the project as it evolves. There is no use discussing resources on a project, unless this condition is met and unless perceptions on the why and what of the project at hand are aligned. Once this condition is met, at least resource issues will be understood the same way and, as a whole, your organisation’s project portfolio will be balanced over time to assign the proper resources on your projects. This includes those organisational change projects that are perceived in many different ways by the stakeholders, none of these ways being the right perception, because it is not a shared perception.

 Let’s not forget that famous Einstein quote you saw at the top of this article, “Perfection of means and confusion of goals seem — in my opinion — to characterize our age”. I believe this to be right, particularly in the western hemisphere. I know that organisational resources are not infinite, but I believe we can do a lot more with what we have if we start to work together on the same projects (meaning having a shared perception of why it is about, what it is and what is required to make it happen). Make sure you have common goals, as this will automatically elevate the resource availability constraints… because it will ensure that the right resources are used on the right projects, at the right time. It will ensure that those resources that are already available in successful organisations stop being wasted by being used on the wrong project or at the wrong time.