Destination unknown: can project managers work without a map?
It’s all about the skill of the project manager. It’s a matter of keeping track of activities, re-balancing, taking account of risks, resource constraints, managing scope… Baloney! That will not get the results. The same lame excuses and ideas have been trotted out for many years and the results are no better, and probably worse, than they ever have been.
All the aspects mentioned above are essential to project success. But, IT projects are different because project managers are often working with a lack of clarity of the destination and even a poor understanding of the starting point.
A common scenario for many projects is: the business requirements, functional and non-functional requirements were clearly documented, socialised and agreed. The project was well-managed to scope, review sessions were held regularly, resources were managed well and the requirements were all met. Yet, at the final meeting prior to entering the User Acceptance Testing phase, the new software was demonstrated and the response from some stakeholders was: “I didn’t expect it to look like that”. And these were well-informed, highly IT-literate stakeholders.
The usual response from IT to the stakeholders is:
- Well, that will require some re-work, we’ll need to re-design, undertake more development and that will involve much more expense; or
- We’ve met all the requirements and have a hard delivery date so that is what you’ll need to use.
What chance do project managers have? In the above example, there was no absolute clarity in the destination or the business outcomes that were intended were not communicated in a manner that was easily understood.
Absolutely, we need to get requirements right, but the old approach of having business analysts define tight requirements that guide the IT development has been proven to fail. A different approach is required.
Start with the destination in mind
Back to the fundamentals – what are we trying to achieve? Why are we undertaking an expensive high-risk initiative such as IT systems implementation? It’s not about IT. It’s all about implementing business change or transformation.
Successful transformation is dependent upon knowing where you are, when you want to go and making sure the project is managed to navigate all the obstacles and inevitable issues that arise along the way. It may seem simple at the outset, like a journey from A to B. it is of course simplistic to expect this is a straight line and that journey will be without incident.
Good project management is essential to make sure you keep on track. There will be issues with project resources, expectations, stakeholder availability and reliance on external parties that will add risk to the project. Experienced project managers are well aware there will be some unknowns that arise during the project and will manage accordingly.
While this may not result in the most efficient straight line to the destination, the corrections may be made within the contingency that was allowed at the commencement of the project. Hence, you can arrive at the destination and deliver the expected benefits of the project.
But, this relies upon having clarity of where you want to head. In many projects such as infrastructure projects, a great deal of time and effort is invested in providing clarity of the final destination. There may be a scale model or a prototype of the final product, whether that is a building, rail carriage, transport network or house drawings and plans.
In IT projects we rely upon requirements. These describe in conceptual terms the end product that we desire to deliver and that should enable the expected business outcomes to be achieved. The set of requirements is provided to business people to sign off and this then forms the ‘contract’ for the IT portion of the business transformation. This is a failed approach and has been proven many times to be totally ineffective. Just look at the success and failure rate of projects.
Why? Business people do not understand requirements documents and cannot be expected to. How can anyone read 6,000 requirements statements and be confident they represent the business outcomes that are desired? It would be like being provided a set of building specifications for your new home with no plans or diagrams of what the building will look like. Would a homeowner sign this off?
Even with agreed requirements, we often set off in the wrong direction and then expect strong project management, managing expectations, avoiding scope creep, attaining the right resources and other good project management discipline, will ensure the desired business outcomes are achieved. Good project management will keep the project on track, but this may well be the wrong track.
We take the wrong track because the requirements, while useful for delivering IT systems are not representative of the needs of business.
What’s the answer?
Is it agile development, user experience design or prototyping? Certainly, these help to provide a clearer understanding of the how the IT system may look and perhaps how people may interact with it but this is still only part of the picture.
The big picture is the total environment that consists of people who perform the work, usually by following process, that need to comply with policies and regulations and utilise IT systems to enable more effective results.
Business people should not be asked to sign off on a set of requirements. They should be presented with a model that clearly shows in their terms how they will work in the future. The model needs to include detail of processes, interaction with systems, roles and responsibilities and enough detail so business people can clearly see in concrete terms how they will operate in the future. The model should be supplemented with requirements in the same way that building plans and designs include specifications. The requirements can then be referenced in a business context, not just from an IT perspective.
Further, a similar model needs to be constructed that clearly shows how the business operates today. There are far too many cases where requirements were missed because the detail of current operations was overlooked and hence not included in the future state model.
These current state and future models pay for themselves. They can be used to quantify the benefits of transformation by comparing costs and effort between the new and the old. They can be used to test the business case for transformation. They become an operational model that helps the business to operate more consistently and more compliantly. They allow better decisions and adjustments to be made during the project to steer towards a successful outcome.
In the worst case, they may suggest the transformation will not provide sufficient returns for the costs and risks identified. While this may be viewed as a cost, the statistics suggest this avoids further investment that should not be made. In this event, the current state model can quickly be used as an operating model, which yields significant benefits.
In the best case, the future state model will be used as the new operating model, helping to embed change so the business does not revert to the old, less effective or less compliant way of working.
