Is your project “Risky Business”?

Long time readers of FNP blog will remember that one of my favorite movies is “Risky Business” starring Tom Cruise.  For those that might not know the plot, it is about a teenager looking to have fun at home and takes a trip in his father’s Porsche – resulting in the sudden need for lots of money, which he raises in a creative way.

I was just reminded of that movie when I read about several Government failures and lack of planning – one being the current U.S. Healthcare Portal (  I wonder how the project managers and stakeholders did their planning for this web portal project?

I would like to talk about four triggers for some recent, very visible project failures, being one of them. Recognize that in all of these failures, good people were working to do their best, but because of key factors (or lack of), things went very wrong. (“There but the grace of God go I” comes to mind.)

1. Failure to address performance requirements. Example: US Government’s

  • How many people will use it at the same time?
  • How will we measure and test for stability?
  • How do we correctly size the infrastructure?
  • How do we launch it to improve chances of success?
  • How do we ensure accountability throughout the team of contractors, subcontractors, and client personnel to reduce finger pointing?

2. Lack of risk management/poor quality control. Example: Texas State IT Project

  • Have we identified all of the risks?
  • Have we underestimated the impact of key risks based on weak assumptions or poor decision making on our part?
  • Do we have a real risk management plan?
  • How will we ensure quality control?
  • How will we make sure we follow through on all quality action items identified?

3.  Inadequate resources/inadequate skill levels of resources. Example: ?

  • How will contractor and subcontract assign resources?
  • Do we have a resource management pool that helps us find resources with the right skills?
  • What is our staffing plan to fill key vacancies?
  • How will we retain key personnel with critical skills?

4.  Poor Scope and Contract management.  Example: National Health Service (NHS) in the United Kingdom’s IT system (Lorenzo)

For those of you who work on government projects, please share your thoughts on why government projects continue to fail.

Scrum Project’s Biggest Risk – Where did the Product Owner go?

Today I continue my series dealing with Scrum.  I mentioned in previous Scrum posts that I appreciated the opportunity to talk in depth with Don McGreal, VP of Training at Improving Enterprise about his lessons learned as a Scrum master. One comment of Don’s that caught my attention because its truth is reflected in my experience as a project manager and project consultant is that the biggest risk to project outcome is the involvement (or lack thereof) of the client or product owner.  (How many PMs have had the “disappearing sponsor/stakeholder” experience before?)

I have had customers who create a product vision and a set of top level requirements and then disappear from interaction with the team (and sight) until the semi-annual review. Don reported on a product owner who did not reappear for a year during development. Scrum success depends on an actively involved product owner. “If the Product Owner is ineffective then the Scrum team will be too,” states the introduction to an Improving Enterprise LLC product owner training class.

10 Tips for getting better customer/product owner involvement

  1. Explain the essential role of the product owner in having a successful development beginning with your first interaction. Use examples that the owner or client can relate to rather than focus on methodology or abstract requirements. All of us have stories of success and failure that can be tied directly to the interaction with the client. Use some of those examples to persuade. Your goal is to help the customer or product owner believe that their active involvement is not a punishment, but an opportunity to make sure the final product meets their needs. The product owner must set the requirements for each sprint. Cast the product owner as a hero.
  2. Train product owners who are new to their role. No one is born knowing how to be an effective product owner. Training and feedback help improve skills and the resulting development. Not to mention that you might actually create a rapport with the product owner that helps improve the overall communications.
  3. Put customer involvement in the contract. This is not a threat to hold over their heads, it is a demonstration of the importance of owner involvement in developing a product that is useful and meets needs.
  4. Get users involved in requirements generation and testing. Because Scrum development is broken down into many sprints, each with a deliverable, product owners or users have many opportunities to interact with the development team. Remember, under the Scrum framework, the product owner “drives or influences” the tasks for each sprint by creating and maintaining the product backlog (which is ordered).
  5. Do prototypes, demonstrations or iterative deliverables. Each Scrum sprint produces a working, bug-free piece of software (Or other demonstrable artifact). Having the users or product owner review and test at the end of each sprint allows developers to confirm that they are creating what is needed or make corrections before there is too much investment in a feature or process.
  6. Tie features to the product vision. Each sprint review should begin by reiterating the final product vision and show how that sprint’s work is part of the whole solution.
  7. Explain decisions and trade-offs. A product owner sets the task priorities for the next sprint. Developers must help the owner in selecting how much can be accomplished during a sprint by explaining technical requirements and challenges.
  8. Communicate. Keep the product owner informed. Make sure they are invited to the daily Scrum “15 minute” status meetings and are participants in the sprint planning and review sessions.
  9. Let the client drive. If product owners do demonstrations of the product developed-to-date during management reviews, for example, their sense of ownership increases as does their feeling of accountability.
  10. Give the product owner credit for their valuable contribution to the project’s success.
The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site