Someone emailed me the other day asking about how to use percent complete to track progress on their project schedule. It’s not the worst way to measure performance, but as I’ve got more experienced at putting schedules together, and the work I do is more uncertain, I’ve got less interested in using percent complete.
It means very little (at least, the way we were using it – which was basically a guess to feed into a schedule that was also mainly guessing given the level of complexity and uncertainty, and changes every week).
So I started thinking about schedule performance tracking – and there are plenty more ways to measure your progress than sticking to percent complete.
The infographic below shares some of the ways I know to measure your performance. You wouldn’t want to use them all on the same project necessarily, but it’s good to have options. Which ones do you use?
On this blog I’ve looked at different Knowledge Areas and how they apply to us as project managers, and also taken a budgeting and cost focus on a lot of articles. But what if you are managing an agile project? How do some of the financially-leaning Knowledge Areas work when you are working in agile ways?
Here’s how. Today, I’m looking at how the schedule management Knowledge Area applies to the agile work process.
Project Schedule Management
When you work in an adaptive environment, your project schedules aren’t going to look like big old Gantt charts. You’ve got short cycles to do the work in. With a lot of the people I mentor, we’re talking two week sprints.
The short cycles allow you to do work, review the work and then tweak the results as necessary, including any testing that needs to be done. Ideally, you don’t want all your features dropping on the testing team on the last day of the sprint because that’s not kind!
One team I worked with had this problem a lot so actually set up testing sprints running ‘behind’ the development sprints, just so there was enough time to test everything. Whatever works.
Scheduling is a cost-driven activity because people cost money, and you need people resources to do the work. That’s why it’s important to understand what scheduling options are available to you and how best to get the most out of the time and people that you have.
This could look like pull-based scheduling – which is what I am doing on one Agile team at the moment. There are a lot of tasks. I have the luxury of being able to decide on my next task. They all have to get done, and I can choose. Within reason!
Or it could look like on-demand scheduling. I have used a scheduling approach on a predictive project where we only planned the next three months in detail and let the rest of it unfold as we got closer to the date. It was the only way to stay on top of the work, on that monster project. It wasn’t a project being run with agile principles, but our just-in-time approach to scheduling made our lives easier. As I said, whatever works.
If you work in a big company, there are probably predictive and adaptive methods in use. All of the projects need to fit into some kind of PMO roadmap that allows the business to strategically plan the change effort.
The Agile Practice Guide talks about using predictive, adaptive and hybrid approaches to combine practices to get the best approach for the project or programme being delivered. Consider what scaling you would need to do to your current methods based on:
However, good schedule management skills are universal, and being able to break down the work, estimate, ensure work is given to the right task owners, track progress against tasks being completed – all those are fundamental skills. The tools and techniques you use to do them might be different depending on whether you are taking predictive or adaptive approaches.
Your PMO should be able to support all kinds of ways of working, and if they can’t yet, they are probably thinking about how to make sure they can in the future, because more and more PMOs are needing to adapt the way they work to be able to better support agile project teams.
From a financial perspective, you should be able to track the resource cost (and any other costs directly related to scheduling, if there are any) via timesheets or the equivalent way of reporting actual hours worked. This is especially useful if your team is not 100% dedicated to your project. If they are only doing your project, and you’re running on a timeboxed approach, you should easily be able to work out how many hours it took you to get the output from this timebox.
Schedule Management as a Knowledge Area is applicable to project managers working in agile environments. As with all tailoring, you take what you need and adapt to the project, team and processes you are using.
Pin for later reading:
We need to measure project performance to see if the project is on track.
The graphic below shares some ideas on the different ways you can measure work performance. None of these suggestions is better than any other – they are all appropriate for different projects, environments and levels of project management maturity.
Do you use any of these approaches to measure progress on your projects? Why (or why not)? Let us know in the comments section below!
For more on this idea, and a bit more background on the performance measures, check out this article:
It’s time to look at another project management Knowledge Area from the PMBOK Guide®-- Sixth Edition. This time, we’re diving into Project Scope Management. I’m going to be looking in detail at the major changes between the Fifth Edition and the current version. It feels like the Fifth Edition came out of circulation a while ago, but I know (anecdotally) that some people are still yet to update their internal processes to align to the Sixth Edition.
In practice, I don’t think that matters much. The changes aren’t radical – and while it’s good for new people being certified to work in an environment where the language and expectations align to what they studied as part of their PMP® prep, no one is going to find it difficult to work in a v5 environment.
So, onwards to this Knowledge Area. Let’s dive in!
Plan Scope Management Process
This is the first process in the Knowledge Area, and it makes sure you are setting yourself up for success. As with many Knowledge Areas, we start by planning out what we are going to do in this domain before getting on with the work.
The inputs haven’t changed from the Fifth Edition. They are still:
The objective of this process is to consider how you are going to get to an understanding of what the project scope is, so you need all of those things.
Tools & Techniques
There isn’t much change here either. Expert judgment and meetings remain as they were before, and there is the addition of data analysis.
You might recall that data analysis was added in as a tool and technique to schedule management too.
Data analysis is a lovely catch all for the kinds of things you might be looking at during your planning. For example, you will probably do some alternatives evaluation to decide which requirements and specific functionality or solutions you want to move forward with.
Nothing has changed here either.
At the end of working through this process, you’ll have the scope management plan and the requirements management plan.
I’d say that if you have a repeatable process in place with solid templates and expectations for managing scope, you should be able to complete the work required here quite quickly. You might not need to write a detailed document for requirements management and scope management, if you can include a paragraph in your main project management plan. There’s nothing in the PMBOK Guide®-- Sixth Edition that specifies you have to have separate documents, so go light on paperwork where you can!
Next time I’ll be looking at the second process in this Knowledge Area: Collect Requirements.
This is the end of my deep dive into the PMBOK Guide®-- Sixth Edition, and what it covers about Project Schedule Management. I’ve looked in detail at the major changes between the Fifth Edition and the current version.
One of the biggest changes in the Sixth Edition is the inclusion of information on trends and emerging practices, tailoring and Agile. This is long overdue and it’s helpful to have some specific guidance around how we can adapt the sometimes dizzying amount of information in the PMBOK® Guide to our own organisations.
To recap, here is the rest of the Project Schedule Management deep dive series:
OK? Let’s take a look at what you need to know about adapting this process for your environment.
Trends and Emerging Practices
Scheduling techniques have pretty much stayed the same for many years, but there are some new thought processes at work. We have to be able to manage in a competitive environment where everything seems to be needed much more quickly. There’s a business advantage to being able to compress schedules and deliver things in a shorter timeframe, so the emerging practices covered in the PMBOK® Guide relate to those.
First we have iterative scheduling with a backlog. This is a common way of managing work in an Agile environment and supports rolling wave planning. In other words, you have a big bucket of requirements (user stories) that are prioritised as you come to the end of a time box, for delivery in the next time box. This works really well when you can or need to be flexible about what features get released when.
The major benefit is that the customer gets to see real progress on an iterative basis. This is great for building loyalty, delivering benefits more quickly and ensuring user adoption over time.
However, when there are lots of dependencies between tasks or requirements, it can become difficult to manage.
On-demand scheduling is based on the theory of constraints. It limits the work in progress for a team so that you can balance demand against what the team is capable of doing. As someone who is not a fan of multitasking (although I do it every day), limiting WIP is a great idea.
Kanban is where you will see this approach in use most commonly. In practice it works because instead of building a schedule based on requirements, you plan around the team’s availability and they take work from the queue to work on it immediately.
This is a good approach in environments where you have people doing a mixture of BAU and project work, and their project work does not have hard deadlines. I have no project experience of on-demand scheduling, aside from using something similar for my own To Do lists, so share your experiences in the comments below – I’d love to hear more.
The PMBOK® Guide talks about the need to tailor the approach to scheduling because every project is different. For your project, think about:
The life cycle: what life cycle are you using for your project and is it the best approach for getting to a detailed schedule?
Resource availability: You might have to switch up how you manage the schedule because of difficulties securing the resources you need.
The project itself: Big, complex projects need a different approach to scheduling to a small, easy project. There might be constraints within the project environment that lead you down one scheduling path compared to another, for example being required to use earned value as a stipulation of a particular contract, or using a particular scheduling software tool because that is what the client uses. That leads us to:
Tech support: What tools are available to you? If you don’t have access to modelling tools, for example, it’s not appropriate to build your schedule on the basis that you can use them. If you don’t have virtual Kanban boards and yet your team is virtual, then perhaps a scheduling approach that relies on specific software isn’t the best way to go.
Considerations for Agile
Adaptive project methods are those that use short delivery cycles. You do the work, review the outputs and make changes as necessary before the next delivery cycle kicks off. We’re seeing more and more projects use agile approaches like this because they work.
However, in my experience, and that of the many project managers I mentor, a lot of companies have project teams doing agile and project teams who don’t use agile. Sometimes we use Agile and non-Agile techniques on the same project (for different aspects of the same project). There’s a recognition now that this is OK. If it works and you get results, then it’s OK.
The PMBOK® Guide talks about hybrid approaches and being able to combine scheduling techniques from different approaches to get where you need to get. As a project manager, you have to make or support decisions around the tools and approaches you are going to use, and it helps to have some experience of these. If you find yourself suddenly managing an Agile project with no prior experience, you’ll be fine, but get familiar with the approaches as quickly as you can!
Pin for later reading: