When we think of the concept of “success,” it often seems relatively straightforward. Looking back on your day, for instance, it’s generally an easy thing to sum up whether it was successful or not. Did your presentation go well to that big prospective client, or did your car break down on the way to work? Were you able to get the gym as you had hoped, or did your boss need you to work late on someone else’s project? Easily definable items such as these, measured against a finite number of other events, allow for relatively rapid analysis.
Yet, when one extends the number of competing factors a bit, measurement becomes increasingly difficult. Just as it is generally easy enough to determine if your day went well, deciding if you had a good year can be a bit harder. For one thing, how do you weigh competing factors against each other when there are so many more to choose from? Is financial success the most important item, or personal fulfillment, or a host of other things that happen over the course of a large timeframe?
These questions are the same ones that face project managers every day, as they struggle with the ever-present dilemma of demonstrating success to project stakeholders. The first real issue is that few projects have just one stakeholder, and each stakeholder may have their own definition of success.
As noted by William R. Duncan in Defining and Measuring Project Success:
“The health and safety officer wants no injuries. The manufacturing manager wants a product that is easy to build. The ISO 9000 compliance team cries “success” if the documentation is complete. The VP of Marketing will be delighted if you get to market before your competition.”
This can be especially true in the training field, where the training department’s ideas of success can be vastly different from a harried team manager who wants to minimize lost productivity due to excessive training.
So, how can a poor project manager navigate these dangerous waters?
Preparation, preparation, preparation. And by that I mean, documentation, documentation, documentation.
It is imperative that your client recognizes, in writing, that a, b, and c factors constitute success, while factor d is not important and should not be used. Since you may have only one immediate contact, often within the training department, it’s a good idea to dig deeper. Ask for sign-off on the success factors from all the key people, whether you’ll meet them or not (this helps your immediate contact, too, which is pretty handy).
Furthermore, note the assumptions on which these success factors are based. If your client wants you to get an elearning module built based on storyboards developed in-house, make sure it’s clear that your work is entirely dependent on their work. And make sure it is documented and clearly understood how to escalate those issues up the chain of command, if you have to.
Finally, don’t oversimplify when writing out the success factors, but don’t over-measure, either. For example, writing “All milestones will be completed on time” as a success factor doesn’t give enough leeway that you may need in the normal course of events. William Duncan suggests using a structured format to overcome oversimplication. His example:
- Stock intro: “one key success measure for this project is to have…”
- Measurable item: ‘the completion date of every major milestone”
- Comparison statement: “within”
- Some number: “one week of the baseline schedule date”
This example provides specificity and flexibility, all at the same time. The result is a measurement that is easy to understand, and leaves wiggle-room where appropriate.
Ultimately, these ideas only scratch the surface of what is important in demonstrating success to your client. The ultimate truth is that success can only come from communication, so talk with your client.