How to Manage Project Risks, Part 3: Design Risks

Some years ago, the task of implementing a change to how field crews were organized was delegated to a manager. A few weeks later he proudly reported a successful implementation. We looked and were horrified. Not because he had failed in his implementation, but that in his design of the solution he had reinforced the role of the Field Crew Supervisor and disempowered the crews themselves, when one of our stated corporate goals was increased staff empowerment.

Throughout the project staff will join -- database experts, analysts, programmers, testers, change experts, or whatever. They will not have been around at the beginning of the project or when many of the key decisions were made regarding the project, its solution and implementation. They need some parameters within to work, otherwise they can design solutions that meet the written specification, but are exactly what you don't want, as in the example above.

Design risks deal with the risk that the design of any dimension of the solution (including the change management elements) may not be what you wanted or intended.

It is not possible to easily and clearly specify every dimension of a solution in the specification. For example, with a block of flats, the materials and finish can be specified, but those working on the job also need to know the ambience and market positioning of the flats -- are we targeting the top of the market buyers or first home buyers?

Talking to a group of tradesmen recently they were quite clear that they had different ways of working (with associated cost impacts) depending on the desired quality of the outcome.

Design risks cover the dimensions that are usually 'unspoken' or, worse, assumed. Development of design risks is done most easily by defining what you don't want! People are far happier stating, "What we don't want is. . .

• existing contracts to be breached

• any rules, regulations or laws to be breached

• new users to require extensive, multi-day training to learn to use the new . . .

• our technical architecture to be made more complex, and so on."

Where relevant positive values and goals exist, such as our "increase staff empowerment" or "simpler to use systems", these must also be included. -- -PB -- - Once the negative, what we don't want, parameters have been defined, they need to be restructured into positive parameters, such as

• All existing contracts will be honoured in full, except by mutual agreement by the parties.

Each design risk parameter should be supported with information to help people comply. Where do they find out about the existing contracts? What are the usability measures for the user interface? What is the technical architecture? What is meant by 'staff empowerment'?

Failure to either identify or enforce the design risks and their parameters will often result in your project's solution not matching expectations or, worse, essential requirements.

To read Jed's last column, How To Manage Project Risks - 2 Critical Success Factors click here

Jed Simms is CIO magazine's weekly project management columnist. Simms, founder of projects and benefits delivery research firm Capability Management, is also the developer of specialized project management and project governance Web site www.project-sponsor.com

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email CIO
• Follow CIO on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark