What would project planning be like if every task, decision and event were given the same weight and significance? It would all just be “noise”, without a meaningful way to monitor progress or plan next steps. That’s the point of the project milestone – to quiet the “noise” and provide actionable goalposts to manage by. Read on to learn how it works.
First and foremost, project milestones are scheduling and status devices, used as "yardsticks" to measure progress throughout the project lifecycle. Here’s a quick list of the most common possibilities:
From a more strategic perspective, milestones are "tools", providing the means to define project priorities, monitor progress and tell a more meaningful "status story". They are first identified and defined during the “project definition phase”, when project “concepts” are broken into specific, actionable terms. This plays out in a sequence of three (3) key steps:
The key to milestone use and identification is meaning and significance. By definition, every task and result cannot be a milestone. To warrant that designation, tasks and results must be of such significance that they tell the "status story" in and of themselves, even without any details relating to the specific, underlying work elements. For example - if you are developing a new software product, daily coding tasks will not be milestones, but having sufficient code for usability testing would be. Project milestones are used to manage the project work effort, monitor results, and report meaningful status to project stakeholders.
Key Criteria for Milestone Selection:
Note: To a certain degree, milestone “definition” is not limited to the definition phase. In practical reality, milestone definition occurs throughout the project management lifecycle. Change is a fact of life in every project, and as project terms and circumstances change (as the project unfolds), milestones must change as well. Some milestones may be eliminated, some may be modified and new ones may appear. The extent of milestone definition throughout the project lifecycle will depend upon the nature of the project and the extent to which changes are allowed.
Once milestones have been identified and defined, and actual project work begins, related oversight obligations kick in. As project work is executed, identified milestones will either be met (in whole or part), missed in entirety, or will be modified as needed to suit changing project needs and circumstances.
The key to milestone management is to be informed and prepared, so you can act swiftly if and when problems occur. If you know that one or more milestones will not be met, the goal is to minimize negative impact while adhering to all previously approved fast track priorities. Responding to missed (or about to be missed) milestones will best be determined based on circumstances, capabilities and fast track priorities. No matter the response, communication is the key. Stakeholders must be kept fully informed to minimize negative perceptions, establish realistic expectations, and obtain important feedback to solve problems and/or re-negotiate previously established priorities. How does it work?
Project milestones are more than scheduling devices (which would be important enough), they are also communication and credibility devices, to set expectations and share status information. As milestones are reviewed for status reporting purposes, the following questions can be addressed:
Tip #1: Project milestones are one of the most useful (and used) variables to establish management benchmarks and quantify progress "to date" once projects are underway. To maximize the potential value, every SOW and/or project charter must incorporate “milestone definitions”, stated in sufficient terms to set expectations and allow for informed consent.
Tip #2: At the heart of the matter, milestones set the stage to measure progress, and as such, they must be defined at the start, before costly work begins. Without the means to measure progress, your project can quickly get out of control and you may miss important signals regarding plan viability (or lack thereof).
Tip #3: When it comes to identifying project milestones, the best advice is to keep it simple - you'll know a milestone when you see one. But there are rules of thumb. In most cases, the dividing line distinguishing "milestone" from "non-milestone" is significance, impact and value, all influenced by project specifics. And, when it comes to milestones, experience may very well be the best teacher. That’s why the “milestone process” should always be evaluated as part of every post-project review – so you can learn from experience and improve related predictive capabilities.
About Us - ITtoolkit.com has been around since 2001. We started with a few articles about IT projects, and since then have developed our own series of time-saving practices and Toolkits for managing projects and IT services. The article above is part of of our full catalog of "how-to" articles, filled with these techniques (which you won't find elsewhere) to help you get better results in less time. We cover all the basics and then some - including projects, IT services, team building, disaster recovery and more. You can continue with our recommendations above, browse the articles catalog, or download free templates and whitepapers. And, visit our home page to learn all that our Service Strategy and Fast Track Project Toolkits can do for you!
Subscribe to the ITtoolkit newsletter for the latest articles and updates.
See the latest in our collection of IT Management Infographics. Visualize I.T.!
It's certainly possible to manage IT without having a strategic vision, but why would you want to? A strategic vision makes it easier to achieve IT management success, realize added value and fulfill service expectations. A strategic vision is the quick path to make IT more relevant, realistic, responsive and accepted. And that's what IT's all about!
Get a "big picture" introduction to all the key concepts and elements of strategic project fast tracking in our series of online articles:
There's no doubt about it - projects are risky propositions. Surrounding conditions are unpredictable - sometimes capabilities meet demands, and sometimes they don't But one thing is for sure -- you are always expected to deliver. That's what strategic fast tracking is for -- to make sure you can deliver even when project conditions are not what you need them to be.