Project Assurance Resources

Setting Project Milestones

The information in this guide is intended for general purposes only. For more specific guidance around your organisation’s projects, please get in touch with our team.

In this section, you will find:

Chat to any project manager in the midst of a big project and their mind will likely be on budget or milestones. Whilst stakeholders, their team and the delivery itself are also important factors to be thinking about, there’s never really a moment where the schedule isn’t being considered. After all, one measure of a successful project is the timing of the delivery; a leadership team or board may be expecting an outcome that has a dependency on that project’s completion. Missing those deadlines can affect performance right up the chain and create more conversations that aren’t always enjoyable!

With that in mind, why do so many projects go over the timeline they thought they’d deliver to? The longer answer incorporates all the risks and typical issues that a project encounters such as people, technologies, vendors, market forces, policy and a whole host of other things.

But the short answer is that milestones are often missed when they’re not set realistically or protected through other business decisions and strong governance.

Milestones aren’t just a matter of keeping higher-ups satisfied that progress is being made. They’re essential for project delivery teams to recognise their achievement at key checkpoints along the way. Keeping a team engaged with the project is often reliant on their ability to see the results of their work.

In this guide we will provide some ideas around setting project milestones that can help organisations be prepared and equipped to hit their objectives on time.

IQANZ_blog_Feb2_3

Getting clear on the project’s ultimate objectives

A lack of clarity is kryptonite for a project. When project teams, stakeholders and leadership have different views on a project’s purpose and goals, you can almost guarantee there will be problems down the road for sign off. This can directly lead to milestones being missed and budgets being exceeded.

It’s up to the owner of the project to craft a clear business case with ties to the outcomes the project will drive. This will be developed ideally with the contribution of a nominated steering committee or similar group that represents the objectives of senior leadership. Asking ‘Why?’ should never be a question anyone’s scared to ask; everyone right down to your delivery team’s most junior member should be able to describe simply why they’re doing the work.

Capturing these objectives somewhere central and visible is a great idea at the very beginning of the project. New projects often lack the internal communication across the organisation as to why they exist. In our view, this a missed opportunity to remove mystery and even garner support across future potential stakeholders.

Once the objectives are agreed upon, it’s time to build a scope of activity that directly realises these goals.

Having the scope nailed down

Scope creep – even those outside of project teams in many organisations will be more than familiar with this phrase being mentioned in meetings and around the water cooler. It continues to be talked about because the issue still remains – protecting the parameters of a project from irrelevant or impractical additions.

Keeping to milestones is directly tied to a scope that’s firm and clear. In your scope, you’ll want to specifically identify the functionality or outcomes of the project, and spend as much time defining what is excluded from the project deliberately.

It’s in the scope document (or your preferred format of capturing this) that you’ll want to outline things like acceptance criteria, known restrictions you’re working with, assumptions, and the aforementioned ‘out of scope’ elements.

Building the scope out should be done with time and care. At this stage of the project, organisations will typically engage a number of parties such as business analysts, leadership and project stakeholders. The more considered the scope is before a day of work is done on the project, the less chances of something happening to derail it.

The scope ultimately should be signed off by all key parties as well – it very well may be referred to at a later date when discussions about ‘in and out of scope’ come up and threaten to affect your milestones.

Defining deliverables of the project

With the purpose and scope of ‘what’ the project is, you’ve got the raw information to clearly define the deliverables of the project. It’s the path to achieving these deliverables that forms your milestones. By reverse-engineering your timeline from the key pieces of work the team will produce, the milestones will hold a lot more weight with stakeholders as they can point to the progress (be it a system functionality, development of a business unit, or new premises – that depends on your project).

Defining deliverables, like a purpose or scope document, needs to be plain english and something that can be pointed to. For example, “the business offers a digital first approach to its clients” is not a clearly defined project deliverable (and may have more to do with a programme initiative), whilst “Personal details view via portal” may very well be a deliverable in a timeline of features that make up a project to build a customer-facing portal.

When deliverables get too esoteric or fluffy, they can lose any sense of relationship to stakeholders and as importantly the team working on them. We encourage clients to make deliverables very black and white so they can be picked up and applied to a gantt chart without too much worry.

Each deliverable should also come with it a list of sub-deliverables or tasks that may inform the project plan at a more granular level. This will be critical when helping your project delivery team plan and execute on their duties.

Building a project schedule

As you can see, hitting your milestones is a matter of getting the highest level objectives nailed, and systematically working through everything that sits underneath this as well. By the time you map out a schedule of activity, the hard work of deliverables and their connection to the project’s ultimate purpose should be squared away.

The project schedule will need to provide more than just the big milestones. Each deliverable comes with dozens of smaller tasks that for a delivery team, reflect their day to day work the most. So in our example around building a customer profile/details screen for a portal, there may be sub tasks like:

  • Connecting the front end form to a database
  • Ensuring security systems to protect these details are working
  • User testing for the screen
  • Front end design

Each of these sub tasks may be reflected in a project schedule as a sprint or other module of work – this depends on the methodology being run in your organisation.

Outlining the resources required

Having enough people to deliver to your plan is a matter of understanding the deliverables and the skills needed. This should start right at the beginning of the project, but can be refined as the project schedule is developed. It’s common for organisations to engage their business analyst roles to work out the specifics of contractors or permanent staff needed to do the work.

You’ll also want to define the elements of the project that are reliant on external vendors. For example, many technology-based projects will use a 3rd party vendor who develops functionality or supports the internal project team. They may also provide proprietary software that constitutes part of the delivery. Getting these parties committed to milestones is a vital step in the process.

Establishing clear indicators a milestone has been hit

Whilst you may have set out clear deliverables and dates for completion, projects often need a number of measures in place to determine if the milestone is achieved. For example, a successful roll out of a client account management view in a portal may need to meet testing, security and stakeholder approval before it can be considered fully delivered, even if the ‘work’ to create it has been done.

Don’t make the mistake of attaching milestones to just the delivery team’s efforts – this creates risk of delays when those finer details pick up something that requires rework and thus pushes the timeline back.

IQANZ_blog_Feb2_3

Building in contingency to milestone completion dates

Things don’t go to plan in every project – whether that’s minor or major often has to do with the level of preparation that goes into scoping and planning the project. Contingency gives a buffer against budget and timelines to navigate unexpected roadblocks and still stay on track. For that reason, we suggest that clients think carefully about their milestones in terms of real world scenarios vs. best case scenarios. It’s better to get agreement on longer stages of the project now rather than explaining and negotiating more time when the milestone’s already passed.

As we provide assurance to organisations around their project, we’re able to support business cases for a longer more realistic duration between milestones.

Having a clear risk / threat profile for each major project milestone

Dealing with issues throughout a project is not about avoiding them, but having visibility and plans for them if they do arise. As part of strong governance, risk assessment and mitigation strategies help milestones be set realistically and be met.

Getting in front of threats that could derail completion of a stage of your project may take some more time before the project commences, but the benefits will become quickly apparent when things are kept on track.

Defining accountabilities for deliverables

Every deliverable of a project, from sign off of a stage, to responsibility for a task or anything else should have a name next to it. Accountabilities help keep progress efficient and everyone involved in their role to play in reaching the milestone. If a certain requirement is not met, there is a clear path of communication in place. We’ve encountered projects where one part of the team thought another part of the team was delivering a key element of an activity. Because neither group was formally assigned the task there was no clarity on who owned it, and neither group actually did the work. . When no one’s on the line for something being delivered, it often won’t be prioritised.

Staying up to date with reporting and governance allows milestones to be hit

The governance on a project isn’t a matter of setting up a strong framework from the outset and leaving it alone after that point – it’s a practice of project delivery based upon regular reporting, communication and progress assessment. Information within a project really is power, and an accurate view of progress and roadblocks that reaches right up to the leadership team will foster buy-in and importantly support when challenges arise. When governance is missing or incomplete, there’s a direct correlation with a steering or leadership team’s ability to affect change and make decisions.

Communicate milestones regularly with the project team and wider business

Communication really is key and so often a problem area in organisations running multiple projects. Communication manifests in a variety of ways including:

  • Regular in person catch ups about the work.
  • Stakeholder meetings.
  • Delivery team meetings.
  • Project manager meetings with programme manager or leadership.
  • Email updates on progress to stakeholders and wider business.
  • Meetings surrounding reporting and governance.

Having clear and simple milestones gives a frame for progress reporting. They paint the picture of how far through your project you are and give both the project and its stakeholders a common view.

Where to next?

Read our other project resources:

IQANZ_blog_Feb2_2

Setting project milestones

Staying on track isn’t just a matter of delivering on time, but controlling costs too. We offer some useful tips when setting project milestones.
Learn More >>

IQANZ_blog_Jan2_3

How to avoid project failure

Project failure is something every organisation wants to avoid. We touch on some of the approaches to preventing things going wrong.
Learn More >>

IQANZ_blog_Jan2_1

Identifying project risks

Risks exist in all organisations. It’s how we prepare, adapt and navigate these risks that makes projects successful. Read our guide on spotting and dealing with risks to a project.
Learn More >>

IQANZ_blog_Feb2_1

Understanding project governance

All the structure and processes around how a project is delivered can mean the difference between a successful project or not. Learn what governance is and how it can help.
Learn More >>

IQANZ_blog_Jan2_2

What causes scope creep

Scope creep affects every project manager or project team member at some point in their career. In this guide, we explore what some of the causes are.
Learn More >>

IQANZ_blog_Jan1_4

Managing project stakeholders

In this guide, we offer some tips for managing stakeholders to keep relationships positive and projects on track.

Learn More >>

Latest Project Assurance Articles

Explore our other QA services

Programme Assurance - Icon by Vector Market - The Noun Project

Programme Assurance

Portfolio Assurance - Icon by DinosoftLab - The Noun Project

Portfolio Assurance

Business Case Assurance - Icon by YuguDesign - The Noun Project

Business Case Assurance

Technical Quality - Icon by Iconiqu ID - The Noun Project

Technical Quality Assurance

Post Implementation Review - Icon by Bold Yellow - The Noun Poject

Post Implementation Review

Other Services - Icon by Bold Yellow - The Noun Project

Other Services

Get In Touch

IQANZ Limited
Level 2, PSA House
11 Aurora Terrace
PO Box 11-757 Wellington,
New Zealand

04 473 4340
info@iqanz.com