By Erin Marandola, Contract Administrator, PMP
Simply stated, a successful IT project is one that is completed on time and within budget. But, how do we get there, and why are there so many project failures? From a service provider’s perspective, a successful project avoids scope creep (the project getting out of control), which adds cost, time and risk. The successful project should also avoid gold plating (the addition of unintended added features to the final product of the project). These pitfalls can be easily avoided. In this blog, I’ll review how properly defining requirements can contribute to a thorough, well-thought out Statement of Work, and lead to a successful project.
If there is a mutually agreed upon Statement of Work outlining the project scope, deliverables, acceptance criteria, and assumptions, each party should have a clear, equal understanding of the project, right? Not exactly. A key factor in project failure is neglecting to exhaustively define and document project requirements within the Statement of Work. When we withhold information, assumptions are made. Since we don’t all think the same way, this can lead to the service provider believing certain terms and conditions are true, while the customer believes otherwise.
Looking back at my career, a few project failures come to mind. In one case, there was a different perception of what was considered in and out of scope between various parties. For example, the Statement of Work said “Eight (8) hours of post-implementation support.” The customer assumed the provider would provide support to end users, but the provider assumed the support would be at the system level and provided only to system administrators. In another case, assumptions were made while scoping the project and writing the Statement of Work, but they were never documented and validated by all parties. This resulted in an engineer arriving onsite for an Exchange upgrade, only to realize the project could not be completed based on conflicts in the client’s environment. It was assumed the customer had a Disaster Recovery solution in place that would support the upgrade, but that was not the case. Had the requirements been documented, this would not have happened.
Register for our upcoming webinar to learn more about project management best practices
To create a comprehensive Statement of Work, we need to methodically define requirements. The most crucial ingredient in defining requirements is the stakeholder, defined as anyone with a vested interest in the project, or anyone that will be impacted by the project. Stakeholders should be included in meetings where scope and requirements are being defined. They can open our eyes to the impacts the future project will have on the organization, environment and processes. They can also help define what the business and functional requirements are, and what constraints might hinder project objectives. Additionally, stakeholders help define what assumptions the project team is working under and how project success will be measured. The benefit of stakeholder involvement in defining requirements is the collaboration – the stakeholder meetings facilitate consensus amongst participants, ownership, and buy-in in the project. The collaborative approach allows stakeholders to assess multiple options to reach the project goals and mutually agree upon the best fit.
Once the requirements from the stakeholder meeting are defined, progressively elaborated and documented, a Statement of Work can be created incorporating the feedback. Prior to mutual execution of the Statement of Work, it is crucial that the service provider and customer review the document together to ensure both parties understand the business need, desired solution, assumptions, and scope of work. The Statement of Work should be updated as appropriate based on feedback from the review session(s).
In summary, defining requirements early on is essential in keeping a future project on track, in scope and in budget. Stakeholders are an invaluable resource in defining requirements. Defining, documenting and incorporating requirements into the Statement of Work results in a document that is clear, through and easy to manage to, helping to avoid some of the pitfalls we earlier alluded to. Best of all, defining requirements leads to a project that meets the true needs of the organization. If you’re looking for more information around IT project management, our VP of Project Management and our Director of Project Management are holding a webinar on January 23rd to discuss the benefits of creating a Project Management Office.