Every project, business, and organization has customers or stakeholders. “A stakeholder is a person or group who has a vested interest in your project.” There would be no measure of success without them! How could you say you succeeded if no one cared what you were doing? Customers are not only external; they exist at every level including internally. Think about it, the project manager answers to the project sponsor and the end user. The project team answers to the project manager and to other members of the team, the software engineers responds to regulatory organizations and to the system engineer, etc. You can see where this is going. If you are a supervisor, have you ever considered your employees a customer? They are as much your customer as the project sponsor.
Do you know what your customer wants from you? One excellent technique is to list all the customers (internal and external) to your project team then interview each stakeholder to outline their requirements. Do not assume you know what your various customers need. If you were building a large communications system, this is obvious as is applies to the end user. Most organizations do a fair job of capturing the end user requirements. Efficiencies can be found in this manner, who knows? Perhaps you will discover that you have been spending hours every week preparing a report that no one needs!
Wait, we are not quite done! In order to ensure you are meeting the requirements set by your various customers, develop metrics that are measurable, repeatable on a set time line, and will allow you to track if you are meeting the needs of your customers. The metrics are a key point in the success of a project, they will indicate when an area is slipping. Exercise caution here, the metrics do not need to be complicated (necessarily) and ALWAYS make sure you are measuring the right things.
Have any of you gone through the process of really identifying your customers? How did that experience go? What did you learn about your project or your organization?
Works Cited
Frost, Bob. Designing Metrics. Dallas: Measurement International, 2007. Print.
Tim,
Very good point about metrics! The time spent ensuring the metrics collected are appropriate and useful will save hours of wasted time in the future.
This is certainly some thing I need to find more information about, appreciate the post.
Good post. A word of caution about metrics though; they can be a great tool or they can be a huge waste of time. Rarely are they somewhere in between. When deciding what metrics to collect, ask yourself the following:
1. What is the range (max & min) for the expected values?
2. What does it mean if the metric goes outside the expected range?
3. If a metric goes outside the expected range, do I have any means to correct it?
4. What types of things would I do to correct it?
If you can not answer questions like these, then you might just be tracking metrics for the sake of tracking metrics. If you can answer the questions above, then you probably have a good tool to help you monitor your program.