PM Practice: Using Milestones

While hiking on a trail outside a Swedish town where I used to live, we passed a milestone on the side of the path. This piece of stone was about a foot wide, 6 inches thick, 4 feet high and many hundreds of years old. There were a couple of features about it that caught my attention.

It was easy to spot from a distance, but it didn’t take up much space. The face of it was inscribed with one number indicating where we were on the path and a 2nd number informing travelers how far it was to the next major town. As we walked along the path, we were either moving towards it or, having passed it, moving away from it. The time that we spent ‘at’ the milestone was maybe a second. The parallels to project milestones make it clear why these ‘moments on the path’ share the same moniker:

• Milestones provide a clear measure of progress and are uniformly visible to all stakeholders. When you pass the ‘Design Complete’ milestone, pencils go down and girders go up. If you’ve still got a pencil in your hand, you haven’t passed the milestone yet.


• Milestones have no effort associated with them. Tasks do. ‘Design Complete’ is a milestone. ‘Complete Design’ is a task.


• Milestones have no duration. They’re just markers on a path. If you stop to marvel at your accomplishments upon reaching a milestone, fine - many people do. But that’s a task (‘Admire Progress’) that has nothing to do with the milestone.


• Milestones are either 0% or 100% complete. There is no ‘50% complete’ for milestones. Once you complete all the tasks needed to reach the milestone, the milestone is passed. Until then, keep working.


• Different milestones may hold the interest of different stakeholders. ‘Key’ milestones are of interest to everyone and often associated with either a major deliverable (‘Test Case Creation Complete’) or a change of the project phase (‘Testing Complete’).


• Milestones are placed with reasonable regularity. I aim for some kind of milestone about every 4 to 6 weeks. Agile Project Management leans heavily on this idea because sponsors need only commit to the process incrementally.


• Key Milestones are on the critical path. As a communication tool for progress, they work better when they don’t wobble around due to float.

Some milestones existing today have been in place for centuries, yet still convey accurate information (Stockholm hasn’t moved). They tend to be stable. Project milestones are similar.

PM Laws: Who Defines Project Success?

When joining a project, I often ask team members to tell me a bit about previous projects. It helps me to understand their perspective on project work ... and keeps me from being (as) surprised later.

I'll ask them to tell me about a successful project and what it was that made it a success. I hear lots of reasons such as a great team, got to use new technology, build what 'I' wanted, requirements didn't change, ... When I ask why the sponsor or key stakeholders thought the project was successful, the confusion sets in. Some team members tell me that the sponsor was not happy with their successful project. More commonly, they simply don't know whether stakeholders considered the project a success or not.

This perplexes me. How is it possible for team members not to know what their stakeholders think about the project? This form of 'tone deafness' is a huge risk for project failure.
It's completely fine to be proud of the work we've done on projects, to enjoy being part of a particular team, or to get a chance to work on something really new. In the end, however, the success of any project will be defined and judged by those that initiated and paid for it. Just keeping this on the team radar goes a long way to ensure that the work being done is moving the project towards success.

So, the project you just finished ... was it a success? Says who?

PM Views: Chaos in Project HR

Finance, Operations, Strategy, R&D, Marketing & Sales, HR, Technology. These are the functional pillars of organizations. I've wandered through the consulting landscape of these areas in both project and non-project organizations, and I have found HR to be far and away the most broken. The ancillary 'personnel administration' aspects of the discipline are fine - things like records and rules are handled as well as anything else in organizations. But the core value that HR can offer - leadership in the getting and keeping of the right people - is abysmal in the vast majority of organizations I've encountered.
Why would this be? The talent management folks I've met are just like other parts of the organization. There are enough inspiring, capable individuals sprinkled among the discipline that it should be possible to do better. Maybe the size of the failure hints at the complexity of the challenge? Think about this:

• There is reasonable evidence that 'superior' work performance can be predicted (though not perfectly) based on a combination of raw mental horsepower coupled with a set of about 20 competencies (e.g., results orientation, resourcefulness, ...). Personality tests may not predict work performance so well, but can provide clues about related factors such as whether your Einstein will show up or not.
• The overwhelming majority of recruitment and selection processes in organizations focus on education, experience, and technical knowledge. The predictive ability of these factors is much weaker than competencies.

It's amazing how often I hear HR staff claim that they need a project manager with knowledge of 'System X' because they need to be able to talk to the programmers on the team. I may be way off base here, but that sounds like a communication competency, not a technical one. I've managed many a project (successfully) where I didn't understand the ins-and-outs of the technology, but I could pick up on when one of my team was concerned about something. In fact, thinking back to my project management failures, it has been on projects where I understood the content deeply - perhaps to the point where I took my eye off the management ball.

So why is HR talent management so completely focused on the wrong things? Competencies are extremely intricate and challenging to assess. It's also expensive, though not as expensive as making the wrong choice for your organization. Experience and technical knowledge assessment on the other hand can be automated (or as I like to say, 'commoditized'). And during high-supply economies like 2009, the push to emphasize throughput over value is even stronger. Unfortunately, a lot of companies are simply missing the best individual faster ... and it peels dollars you don't see right off your top line.