Rethinking Project Success and Failure

October 30, 2009 — Bruce McGraw

I think we have an issue in the field of project management.  Defining project success and failure only in terms of on-time and on-budget performance is simplistic and wrong. Software projects are about solving problems for customers.

I have seen countless resumes from aspiring project managers and performance reviews that claim proficiency in project management measured by these two factors only. While they are important components of project management, being on time and on budget does not mean that the end result met the customer’s needs.

On the flip side, being over budget or behind schedule does not mean ipso facto that the project was necessarily a failure. In the real world of software development, the initial requirements that drove the schedule and budget will change. The business environment is always in flux and the problems the customer wants solved will be shaped by changes in their operating environment.  Let me say this one more time:  change is a constant and must be accounted for in any project.

That shift in priorities and constraints is the key reason that project managers must be in constant contact with their customer and stakeholders.

The need to include quality and user satisfaction as part the duties of a project manager is not a new idea.  The DeLone and McLean Information System success model from many years ago offers additional factors that should be considered in evaluating the success of a software project.  Here are their suggestions summarized in Defining and Measuring Project Success by Danie van der Westhuizen:

• System Quality: measure of the information processing system itself
• Information Quality: measure of information system output
• Information Use: measure of recipient consumption of the output of an information system
• User Satisfaction: measure of recipient response to the use of the output of an information system
• Individual Impact: measure of the effect of information on the recipient
• Organizational Impact: measure of the effect of information on organizational performance

I think their last criteria—organizational impact—is really important to track as a measure of success or failure. If a piece of software or even a new process is timely and cost efficient but is never used by the customer, to me that is a project failure. On the other hand, if a project evolves to meet customer’s changing requirements, is used by the customer, and improves the customer’s bottom line—that project was successful even if it took more time to complete and required modifications to cost and scope.

Another interesting perspective on expanding the definition of project success and failure was presented by Scott Ambler writing for Dr. Dobb’s Journal.  He reports on a 2007research project  that surveyed 105 professionals including project managers, IT managers, and business stakeholders about how they comparatively ranked three common project success criteria:

% who agree with this statement

Project managers

IT managers

Business stakeholders

Shipping when the system is ready is more important than shipping on schedule

50.3%

63.1%

73.3%

Providing the best ROI is more important than delivering under budget

62.4%

76.9%

86.7%

Delivering high quality is more important than delivering on time and on budget

78.2%

87.7%

86.7%

 
Clearly a justifiable conclusion from this small survey is that customers are more interested in the utility of the resulting software product than they are in forcing compliance with schedule and cost parameters set at the beginning of the project. It is up to the project manager to work closely with the business stakeholders throughout the development cycle to clearly explain the reasons and benefits of modifications in schedule and cost, so that everyone ends up convinced in the delivered project’s success.

One last thought or rather caveat—all changes have an impact or cost.  While you should always be ready to accept change, it is not something done lightly or without judging the impact on cost or schedule and then getting buy-in, approval or consensus.

Your thoughts on measuring software project success and failure are invited via comments.

Posted in Best Practice, General Project Management. Tags: , , . 1 Comment »

Project Managers–What Does Your Team Want From You?

October 23, 2009 — Bruce McGraw

There are character traits that most of us would like to believe we possess and that we want to find in the people we work with and work for: trust, integrity, respect, and honesty—sort of like the mantra of the Boy Scouts. Good project managers have those traits and others that make people want to work for them.

What are the traits and behaviors that team members want in their project leader or immediate boss? Here are my observations from being a project manager and observing other PMs—some that were effective and valued and others who were pariahs that employees did everything they could to avoid.

Behaviors Team Members Want in a Project Manager

  • Information sharing. What is happening? What is likely to happen? What effect will it have on me and on the project? Project managers often have access to the thinking and plans of senior management. Although your team does not want to know every machination going on in the larger organization, they want you to be aware and to share information with them in a timely fashion.
    • If you don’t know—say so
    • If you can’t say because you are under a promise of confidentiality—don’t lie. Promise to get the information or temporize with a promise to provide answers as soon as possible.
  • Protection or “executive cover”. Give team members the ability to try things with the security of knowing they will not be offered up in a blame game. Project managers must cover their team on risky tasks or approaches to problems that they have agreed ahead of time; they do not leave them hung out to dry if things go south.
  • Stretch your team with assignments that offer learning opportunities and future advancement potential.
  • Recognize a task or deliverable that is well done and give feedback including upwards in the chain of command. If things don’t go so well, provide guidance and support.
  • Provide a clear understanding of what each team member is responsible for and the metrics that will be used to measure individual’s and project team’s success. Be consistent.
  • Try to solve problems identified by the team whether it is getting a software tool or an adding a resource to off-load some less critical tasks.
  • Be there when the going gets tough—set an example by coming in early, working late, taking an undesirable shift on occasion.
  •  Defend the team from unreasoned and unreasonable demands—when someone says there are four A+ critical projects that must all be done by the end of the week—learn to say no and to compromise with senior managers, marketers, and customers.
  • Treat the team members like people who have lives outside the office.

Project Manager Behavior No-No’s

  • Take credit for the work of others.
  • Treat team members you like better than those you do not enjoy as much.
  • Being a buddy instead of the manager.
  • Inconsistency—sometimes it is okay to be late and another time it is “off with their heads”.
  • Negativity and constant pessimism about the company, the project or life in general.
  • Taking over and solving problems that team members need to learn how to solve on their own—not only do you miss a growth opportunity by doing this, but you telegraph your lack of faith in them.
  • Asking an employee to lie.
  • Offering hollow motivations—see Project Management Buzz words and Clichés – September 4, 2009.

You are sincerely invited to add to this list with your comments and experiences.

Posted in General Project Management, Leadership, management. Tags: , , . Leave a Comment »

Software Usability – Resources for Usability Evaluation

October 16, 2009 — Bruce McGraw

I had an interesting discussion with several people this week that I could summarize this way: “How does software get designed and built that no-one can use?” 

“Usability is the combination of fitness for purpose, ease of use, and ease of learning that makes a product effective.” according to the University of Maryland’s Guide to Usability. Not everyone loves software usability testing. It has been jokingly said that if the software was difficult to code, it should be difficult to use. Unenlightened project managers may even think of users as the enemy. Of course, that is not true. Satisfied users are salesmen for your products and champions of future business opportunities.

However, pleasing users can be challenging.  If you are a software or project manager you know what I am talking about.

In a usable product, says, Dan Costenaro, Microsoft Outlook Program Manager, "Anyone can walk up to your piece of software, sit down in front of the computer, and accomplish their goal. If it’s not goal-driven from the user’s perspective, they will never figure it out." I agree.  Dr. Karen McGraw takes this even further, adding that, “If the user interface is not designed to support the user’s mental model—the way they approach their tasks and work—it will take them longer to learn, accept, and effectively use the new system.”

I wholeheartedly support the increasingly sophisticated tools and processes being implemented to evaluate software usability. Some of these are useful during formative testing, when the design is fleshed out, while others are more effective during summative usability testing.  If you are newly converted to the importance of usability testing or a seasoned veteran always interested in more information, here are some of the resources I suggest you investigate.

A good place to begin is Usability Net’s Methods Table  represented in the graphic below. On their website, each cell leads you to articles and more topic information.  It is worth wandering around on this well organized site to get an overview of usability evaluation.

 

user-focused-testing

 

Here are a few more sites with information on usability testing:

Guidelines for Usability Testing with Children
Microsoft UI Guides and Usability Testing
Performance Centered Design white paper
Usability Professionals Association
Practical Usability Testing from Digital Web Magazine
National Institute of Standards Usability Reports
Userview Remote Usability Testing (I have not used this service, so I am not recommending it. However, the ability to “watch” users interact with your applications remotely could be useful in some instances and they have a free trial available.)</p>

So bottom line for a PM:  Ask your development team what steps, processes and tools they are using to ensure that the interface or product is usable by the user.  If you have had some excellent or unpleasant/unsuccessful experiences with usability testing, please share with other PMs in your comments.

Posted in Best Practice. Tags: , , . Leave a Comment »

10 Project Management Mistakes

October 10, 2009 — Bruce McGraw

Mistakes happen. Bad luck happens. But, when the same mistakes occur over and over again to different PMs on multiple projects, we really should figure out a way to avoid them, but we don’t.  We call this lessons learned in the business – and believe me, it is better to learn from someone else’s mistakes! Although as Douglas Adams tells us in Last Chance to See,

 “Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so.”

Here are 10 of my favorite PM mistakes. Well favorite is really not the right word because it implies something good—like favorite ice cream flavors. Let me re-phrase: Here are 10 project management mistakes I see frequently.

#1.  Over committing key resources. This relates directly to the discussion of the last three weeks on resource management. But it goes beyond that. There is an element of wishful thinking, too. When bidding contracts and developing schedules, ever-optimistic managers are tempted to decide how long a task requires if the “best-of-the-best” are working on it and the wind holds steady.

#2. Believing that good technologists make good project managers. Project managers need people and leadership skills that are not demanded of the technologist. The problems that PMs are called upon to solve often require working through and influencing others on the team.  I often see a job description for a PM that involves lots of required technical skills and none of the people skills.

#3. Ignoring problems. If the PM doesn’t acknowledge that a problem exists, then he or she is under no obligation to solve it.  We sometimes refer to this as the Ostrich maneuver.  Believe me, problems don’t go away by themselves; they usually get worse with time.

#4. Not communicating with stakeholders. The people who care about the project either because they are funding it, reporting on it, or will be using it need to be informed frequently. “No surprises” is the best credo.

#5. Failing to control problem team members. This is one of the more frequently ignored problems because it can be messy and unpleasant. Whether someone is failing to do their tasks or making life miserable for other team members, the PM needs to acknowledge the problem and deal with it.

#6. Failing to manage risks. The risks to successful project completion come in many guises and sizes. Events such as: The new process management software that no one has been trained to use; Relying on an independent team to get their part of the project done on time; Moving offices or changing requirements and not changing the schedule to accommodate the predictable negative impact.

#7. Decreasing time allocated for testing. When project schedules get into trouble and deadlines are not being met, many project managers decide to cut allocated time for testing and user evaluation at the end of the schedule in order to meet the final delivery date. This is always double trouble – you don’t find the bugs and your users or clients are furious.

#8. Learning from experience. Projects should have post mortems and lessons learned that are documented and shared.  I know there is never time left at the end of the project to do this, so try doing a capture of lessons learned during the project at different intervals.

#9. Not controlling requirements. Requirements creep is ubiquitous. Marketing wants additional features, senior management agrees to new capabilities, and future users ask for more, better or different. The PM must provide these stakeholders with realistic estimates of the consequence to cost and schedule of increasing requirements. And sometimes the PM has to say, “no”.

#10. Believing in saviors and miracles.  To quote Pawel Brodzinski—there is no silver bullet.  Or put another way, “Hope is not a strategy!”

 

I invite you to add to this list with your favorite project management mistakes. We can all choose to learn from the mistakes of others no matter what Douglas Adams says about the human condition.

Posted in Best Practice, General Project Management. Tags: , , . 1 Comment »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 354 other followers