The Design Trap: Ways to reduce risk associated with Design Phase

One of the prominent causes of missing the project deadline is the excessive time spent during the Design Phase.  In application development life cycle (web/mobile), design phase is the most crucial phase as it defines the look and feel and to some extent define the functionality of the application. Since this phase requires the customer to be involved and there are lots of reviews, feedback/changes in this phase, it becomes difficult to estimate the exact time that this phase will take.

For projects in which functional requirements are known and the client knows what he wants as the end product, a fixed price contract is beneficial for both the customer and the service provider. However, the organizations which include requirement gathering and design phase as part of a fixed price contract, suffer a lot. Sometimes these two phases together take up 50% of the project time and costs as the design team and client get into a never-ending cycle of feedback and changes.

Even for large projects where the requirement gathering and design phases are in itself separate projects, organizations focus on getting the phase completed on a fixed price basis and more often than not repent later.

Design is also a requirement and sufficient clarity should be obtained on it in the requirement gathering phase itself. One of the ways to manage it is by following a mix of agile/iterative and traditional models. Using a mix of methodologies reduces the risk to a certain extent for the service provider.  

The way it can work is, when the business analysts are collecting the requirements, the UX experts can create wireframes and click-through mockups using any good tool like Axure or Balsamiq and the UI experts then can develop the designs based on it. Not to mention that the client is involved and engaged throughout the process and his feedback is incorporated as the process moves along. Once the phase ends, the development team has clear cut, agreed upon designs to work with and development afterwards can be a breeze. 

Most importantly the Project Manager would have avoided the risk of schedule and cost variance as he would have averted the uncertainty of the estimates. A cost reimbursable contract is best suited for the requirement gathering and design phase while a fixed price contract is suitable for the development and other phases of the project once all the functional, technical & design requirements are scoped out. Another benefit is that there could be requirements or changes that might come to the fore only after the design is ready. This approach takes care of that as well.  

The FP contract can be based on the deliverables of the requirement gathering and design phase namely the working prototypes, actual designs and use cases. 

This also gives the PM an opportunity to reassess the project estimates and avoid/mitigate any risk before the actual development begins.

So in a nutshell

1. Use cost reimbursable contracts for Requirement Gathering and Design Phase
2. Create prototypes as it actually shows user interaction with the application
3. Create Use Cases as it will allow the analyst to consider all the possible scenarios
4. Once the design, prototypes and use cases are prepared, it becomes easy for the developers to develop the application; a fixed type contract should be used for development work

Comments/suggestions are welcome.