Invest in the Project Foundations
Few significant business investments outside of IT would get approval without: a formal process of thought, investigation, discussion across a broad range of stakeholders, a sound plan and budget, all of which could pass muster with the senior management team. And rightly so!
All too frequently, however, even major IT projects get the go-ahead without this fundamental vetting process. In Step 1 we spoke about establishing clear business objectives, to whom they accrue and who is responsible for delivering them. These should be documented in the Project Charter. This charter should be widely circulated, so that everybody even remotely involved with the project understands the responsibilities and authorities. In our interim project reviews we often learn that somebody, sometimes lots of people, knew of an issue long ago, but didn’t know who to tell about it. If left undisclosed, even small issues can disrupt a project at a later date. The project charter defines the rules of the game and identifies the umpire. The charter is also the reference point when reviewing changes to the project plan and budget.
The stakeholder analysis goes beyond the project’s beneficiaries. Even if there are no losers in the proposed process changes, people may be affected. These could be customers, suppliers, strategic partners, front-line staff, or just the mail boy or receptionist (do any of these roles exist anymore?) All those affected should be catalogued, along with the potential implications and a written strategy for dealing with each of them. (More in Step #4)
No business project should be left to IT alone to manage. A Project Steering Committee should be struck, chaired by a business unit leader. It should meet regularly at a frequency commensurate with the duration of the project, but not less frequently than monthly. Minutes should be formal: attendance, project status, issues arising, issues resolved, decision required and made and changes made to the plan / budget should ALWAYS be reported, even in their absence. In Step #9 we will elaborate on what to look for as you review these minutes the moment they are released.
Depending on the scale and scope of a project the plan at this stage may be very detailed or merely an outline of the major stages, events and expected outcomes. However detailed, it should have dates and responsibilities noted, along with the tangible results which demonstrate their achievement. Reaching a deadline does not constitute completion of the phase! What will the persons responsible be looking for at that point? How will they know if it has been delivered? Ninety percent complete should not be considered a deliverable unless the other ten percent is defined and verifiable.
It is only after an appropriately detailed plan is produced that a reasonable budget can be developed. This may not have any correspondence to the initial cost estimate floated when the project was originally suggested. Obviously, the new budget should reflect the business benefits to be derived. It should include the costs to the whole business, not just those of the IT components. And again, the responsibility for, and timing of expenditures should be documented.
Plans, and budget, have a habit of changing. Sometimes good things happen. Mostly, reality is less favourable. It is the responsibility of the project manager, the project steering committee and, ultimately you, to ensure that the plan and budget continues to reflect reality, business objectives and the project charter. If these elements are in place, you have the tools to ensure the project’s on-going worthiness, or alternatively, the justification to call a halt.