The Simple Definition of Value
Categories:
Researching the Value of Project Management
Categories: Researching the Value of Project Management
| A lot of energy has been spent investigating the "value" of project management. My question is: value to whom? Doesn't it all boil down to what the projects' decision-makers do with their project management information? Imagine a project manager who pays a very small amount for a very advanced cost and schedule control system, and the system reliably produces accurate information in a timely manner. If that project manager ignores that output, and instead acts out of impulse, then the value of the project management information system is zero. And, to be blunt, no amount of eat-your-peas hectoring from our side of the debate will lead such a project manager to have an epiphany and turn away from his or her nefarious ways. Conversely, a project manager who pays a great deal for a system that barely reports projected costs at completion and forecasts completion dates, but uses that information to avoid a massive overrun or delay, has an extremely valuable system. Not to abrogate the debate, but, in my opinion, the value of project management is like the macro-economists say: It's what somebody's willing to pay for it. |
Raise Your Voice
Categories:
PMI
Categories: PMI
| No one knows project management better than you, the practitioners in the trenches. For months, you've been weighing in on the blog. Well, here's your chance to have your voice heard in PM Network. Every month, the magazine will run a Voices on Project Management column. Project managers will share ideas, experiences and opinions on everything from trends to new methods of doing things. If you're interested in contributing, please e-mail us your idea. Check out the debut column by Peter Taylor, PMP, weighing in on the pressure for PMOs to perform in tough economic times. |
Planning for the Little Risks
Categories:
Risk Management
Categories: Risk Management
| How many times has this happened on your team? An engineer switches off his machine on a Friday evening, enjoys his weekend, only to come back on Monday to find out the computer won't start or connect to the network. It's a very common problem--and for teams like mine that are close to 50 people--it occurs nearly once a month. It takes the IT team a day to get everything working again, which may push back an already delayed schedule. How do you prepare the mitigation/contingency plan for this kind of risk? It may seem minor, but how many of us even identify these types of little things as risks? We should. In this instance, I suggest the project manager keep a backup machine with the required software and hardware ready for the team. I know it will cost more money, but if you are able to save a day's effort every month then it would be justifiable. How do you prepare for these seemingly "little risks"? See the article, Plan for Everyday Risks, Brace for the Ordinary, by Carl Pritchard, PMI-RMP, PMP, published in April in PMI Community Post. |
The Role of Agile Advocates
Categories:
Agile
Categories: Agile
| This is a continuation of the post Creating Trust in Agile. Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful. Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective? Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed. AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective. The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management. Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology. I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ... Over to you for comment! |
Creating Trust in Agile
Categories:
Agile
Categories: Agile
| Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate. The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership. Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time. The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt. An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end." With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches: We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value. We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way. In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline. To be continued ... |
