Controlling the Cost of a Web Project - Part 2: Discovery and the Importance of Documentation

Aaron Branson
November 07, 2012
Web Strategy

In Part 1: It Starts with the RFP, we talked about the importance of your project's RFP and how it sets the stage for the quality and relevancy of the proposals you receive and ultimately the success of the project. In this post, I'd like to focus on how you can control the cost of your web project once the project is underway. This first critical phase, Discovery, is all about setting expectations, getting stakeholder input and buy-in, and clearly and thoroughly documenting said expectations to ensure there are no surprises in the middle of the project or disappointment in the end result.


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.

Document It!

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! ;)

comments powered by Disqus