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.

Conflicts in projects: Better resolved sooner than later

When we talk of team and people, difference of opinions and conflict are a given. When a constructive criticism may take form of a conflict you never know. Project Management is a dynamic field, and a Project Manager, along with all the project performance related metrics, must make sure that the conflicts to a large extent are healthy and are helping the project. Having said that, he must be on a constant lookout for situations that might result in a conflict that adversely affects the project team and eventually the project.

To accomplish this, a PM also needs to put the hat of a behavioral scientist. He must understand the personality types and behavior patterns of key team members/stakeholders while identifying the stakeholders or developing the project team. Just like a PM is identifying and assessing risks all the time, he should also do the same with conflicts.

A conflict could arise during any stage of the project, from initiation through closure. PMBOK lists following four strategies for conflict management

• Collaborate/Problem Solving
• Compromise
• Withdraw/Avoid
• Smooth/Accommodate
• Force/Direct

While forcing is thought to be the least desired strategy, Collaboration is considered to be the most fruitful for conflict resolution. However, one might have to use any of the above strategies depending on the situation at hand.

Causes of conflict in the project team can also be ascribed to the motivation factors. More often than not, I have seen experienced seasoned team members to be most involved so much so that they are reluctant to confront the situation and are in the Withdrawal mode or being adamant about their stand. If a close analysis is done, a PM can find out what drives the team member. Theories such as Maslow’s Needs Hierarchy can be referenced to do the analysis.

Psychologists James Waldroop and Timothy Butler in their article Managing Away Bad Habits have defined the personality traits of people that might comprise your project team as well as the strategies for handling them.  Their categorization is as follows:

The Hero

Always pushes himself—and, by extension, subordinates—too hard to do too much for too long.

The Meritocrat

Believes that the best ideas can and will be determined objectively and thus will always prevail because of their clear merit; ignores the politics inherent in most situations.

The Bulldozer

Runs roughshod over others in a quest for power.

The Pessimist

Focuses on the downside of every change; always worries about what could go wrong rather than considering how things could improve.

The Rebel

Automatically fights against authority and convention.

The Home Run Hitter

Tries to do too much too soon—in other words, swings for the fences before he’s learned to hit singles.

Understanding your project team under the light of above categorization might also help you focus your action in ensuring fewer conflicts.

Sometimes, there could be frustration among the experienced members for lack of authority or lack of challenging work which might get them into the withdrawal mode. Finding what motivates them and addressing it can at least bring them into Collaboration mode which can possibly lead to a successful resolution and a win-win situation.

Cultural differences need to be taken into consideration as well if the team comprises of diverse cultural backgrounds.

A happy team will always produce better results and it’s the job of the Project Manager to ensure there are less conflicts; a PM should act as glue that binds the team together.