I seriously think this topic could be never-ending. If every project was fully defined down to the last detail, there would never be a misunderstanding with a customer, no scope creep (unless the customer’s business changed in mid-project), few budget overruns (at least less likely), and certainly much less finger-pointing.
As the Project Manager, the responsibility would not really be less or easier, but heading into a project knowing that there would be no question marks sure would make me sleep better at night.
The Customer’s Responsibility
It is my belief that every customer should go into each engagement with their own business processes well mapped out. They also should have a solid list of requirements documented to hand over to the delivery organization. Those requirements are the basis of the Statement of Work (SOW) and then the SOW serves as the springboard to further requirements definition and refinement and gap analysis during the Exploration Phase before heading into the Design Phase.
It is definitely in customer’s best interest to work internally prior to Kickoff with their subject matter experts (SMEs) to do their best job possible defining thorough business processes and requirements for the project. With this task accomplished prior to Kickoff, then the delivery team will be well-informed heading into the project of what the customer truly wants from the system. This will serve several purposes over the course of the engagement:
- Less scope creep
- Fewer change orders
- Minimized risk
- Less chance for budge overruns
- Minimimal impacts to the project timeline
The Delivery Team’s Responsibility
It’s worth noting that the delivery team – and the sales team for the delivery organization – definitely have specific responsibilities here. The sales team must make it very clear to the customer that there is an expectation for the customer to gather with their SMEs and define business processes and requirements on at least a high level prior to the actual start of the engagement. Don’t assume that all customers know and understand the process. Assuming anything during the sales process can lead to unexpected delays and cost increases during implementation when poorly defined requirements and business processes are identified in greater detail and found to be in conflict with the current build of the solution.
Likewise, the delivery team has responsibility. That responsibility includes both educating the customer on requirements definition and helping them through that process during the Exploration Phase.
On some projects, the entire requirements definition process will be and should be a joint effort between the delivery team and the customer. However, on large implementations lasting 6 months and longer, the customer needs to head into the engagement with a good handle on their own requirements for the effort so that the project hours on both sides can be used more efficiently to drill down to more detailed requirements as both sides prepare for the Design Phase.
Summary
I fully believe that it remains the delivery organization’s responsibility – and specifically the Project Manager’s responsibility – to ensure the success of the engagement by managing the processes, the communication, and the information flow that takes place as the engagement progresses. However, the customer shares a great deal in preparing for that success by knowing what they want and heading into the engagement with the right information about how their organization runs now and how it should run after the implementation.
Proper attention paid to requirements during pre-kickoff planning by the customer will allow for both teams to work together to drill down deeper into the requirements and ensure that the necessary detail is in place during the Design and Development Phases as the Functional Requirements Document (FDD) and the Technical Design Document (TDD) are being constructed and developed against.