It has been said that 1/2 of all IT projects fail. They fail for a variety of reasons including scope creep, ever-varying budgets, technology advances, rapidly changing customer behavior, overly ambitious changes the organization is not ready for, lack of internal technical resources, etc, but in my experience, the greatest of these factors is the lack of clearly defined parameters and goals. Whether it’s unrealistic timelines, overly wide decision gates, vague performance goals, or unmeasurable objectives, IT projects are notoriously difficult to complete as originally designed. Regardless of the host of technical folks who are involved, arguably the most important resource associated with an IT project is the project manager / PM.
As a PM, it’s easy to dismiss this as over-inflated grandiose vision of myself personified in other PMs, but the PM’s main role is to document the scope of the project, provide timely and clear communications regarding the progress, either positive or negative, of the project, and reporting both upstream to management and the project stakeholders as well as downstream to the customers, whether internal or external. It is often said that “if it’s not written down, then it didn’t happen.” This is never more true than a large, complex IT project. Failure to properly and officially document project tasks and activities is simply irresponsible. Activities which aren’t written down, simply don’t officially exist. This goes from beginning to end with a complete lessons learned archive to help the next project team.
For instance, in Microsoft’s Windows 95 – 98, there was an icon, a tiny yellow triangle with an exclamation point inside, found in the System Manager which would designated an issue between the actual computer hardware and their associated drivers. Talking with the some of Microsoft’s insiders, a Microsoft contractor had programmed that in as a personal notation to come back and “fix something”. The issue? This line or lines of code were NEVER recorded, and in something like 6 million lines of code, there was simply no way to find it and remove it. The fix? Remove the offending piece of hardware from the System Manager, and upon the next reboot, the PnP / plug-n-play system would rescan the hardware and associate a new version of the driver, clearing the failure icon. For those who weren’t alive during that time simply won’t understand how many hours of production time were lost because of this “undocumented feature”.
Although seemingly harmless illustration demonstrates the need for clearly defined goals and properly documented project tasks from accountability to “now, why did we pick yellow?” to defining progress and lessons learned. Sometimes the most common of tasks which are the most mundane are the most critical to success.
