Discovery Participation and Process
Using the project proposal's scope, you can determine the project "components" and begin scheduling discovery sessions for these that involve the right business stakeholders that have the valuable input necessary to shape the detailed requirements and also have their blessing, if you will, for the direction the project will take.
The agency will involve the relevant people from their team and should consistently include the Project Manager and Business Analyst that will be capturing the requirements gathered during these sessions.
By digging deeper into the project's scope and requirements in this initial phase, we can identify any unexpected "scope creep" such as a feature a business stakeholder was expecting but somehow did not make it into the RFP and hence not the proposal either. So earlier, rather than later when it would be much more painful, such issues can be identified, estimated, and evaluated if it’s worth adding to the project cost and timeline or not. This element of "control" called Change Management will instill a great detail of sanity in the project.
The outcome of the Discovery phase should be a detailed Scope & Requirements document that all business stakeholders are comfortable with and reflects their input. Also, it lines up with the proposal, which in turn lines up with the RFP we talked about in Part 1.
This document should be kept as a living, breathing document that is updated throughout the course of the project as it will constantly be referred back to for other phases of the project – 1) to double-check the UI design has addressed all requirements, 2) to use in writing of QA test cases, and 3) to verify completion of the project...just to name a few.
This documentation is so important in our line of work. The project team and the client must be diligent to keep it current, accurate and realize the impact of changes to it.
Depending on the nature of the project, other artifacts may also be necessary, such as a Competitive Analysis, Creative Brief, Information Architecture (sometimes considered in the Design phase), User Personas, Usability Study data, and Task Flow diagrams.
Stick to the Scope
While documentation will enable you to control cost by managing expectations and provide an "early warning system" for unforeseen scope creep, its typical that some changes will be deemed worth the added cost and time. As often as possible, stick to the scope. But in times where it's necessary, ensure you follow a disciplined Change Management process to prevent the project from being spun off course of its original expectations.
My hope is that these principles will provide some guidance in establishing a solid framework to manage your project and ultimately lead to many successful releases! Oh yeah...that reminds me, Strategic Release Management! That's another important concept to consider, particularly for large-scale projects. But maybe I should save that for a later post. I surely wouldn't want to introduce "scope creep" into the original expectation of this blog post! ;)