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?
We’re using more and more tools now – companies that didn’t previously have online collaboration tools are now signed up to an annual subscription, so even if you can now get into your workplace, a lot of project management teams are still working virtually.
There are changes that come when you add more tech tools into the estate.
You have to invest in keeping your collaboration tools relevant and up-to-date. You should also keep an eye on the future so that if you need to switch systems or link them together, you can. This is interoperability—the ability to use different tools together to provide a single, streamlined technology platform for your company that does not rely on manual rekeying of data.
In my experience, a single platform is better for enterprise data mining, as the fewer interfaces you have to deal with, the easier that exercise is. But it’s also unrealistic, especially if your business strategy has been to invest in best-in-class tools for each area instead of a single, “do everything” enterprise product. If you do have multiple systems, interoperability will help you get the data out.
Traditionally, linking systems together has been through data integrators or other pieces of software that built connections and interfaces between various tools, matching up the records and allowing you to transfer data between them. Increasingly in the online space, interoperability is being provided by third-party tools that handle the feeds for you, allowing smaller businesses to get their systems talking to each other without the need for bespoke developments.
Products like Zapier do this. It lets you build “zaps” which effectively work on a “if this happens, do this” basis. For example, if you upload a file to Dropbox, you can automatically sync it to your project management system.
More tools today are offering application program interfaces (APIs) as well, which are effectively the data standard for that product. By making these standards available, they have done half the integration for you. They let developers build the other half of the integration and match them up, then you can push data into project management tools from other systems and vice versa.
Interoperability is something we need to consider in the broadest possible sense, as well as the impact on tech. We need to do more to understand interoperability between ways of working, blending virtual and on-premise teams and the approaches they use to manage projects.
Businesses don’t limit themselves to managing projects using agile or waterfall approaches. The same company can have project managers using PRINCE2®, Scrum, and A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Project collaboration tools need to be flexible enough to deal with all of those methodologies, and to be tailored to support internal processes as well.
The marketplace today is not full of tools that only support one method, but it is something that decision makers should be aware of—choose a product that supports your future methodology and process needs and not just the approaches you use today.
This article includes a few points that were made in my PMI book: Collaboration Tools for Project Managers. Given what we’ve been going through and seeing so far this year, it felt appropriate to try to pick out some comments on tech for teams and where that might be taking us – because it seems to me that virtual working is here to stay.
Pin for later reading:
What happens when you can’t track project cost?
This happens when other people are spending your project budget and not letting you know where it is going. The first you hear about resources being acquired or a deal being signed is when the invoice gets passed to you from Finance with a big question mark written on it. When this happens you can’t accurately keep track of what is being spent, and whether it is being spent on the right things. How to fix it: Sort out the process for spending money. Make it clear to the project team (even those people who are more senior than you) that purchase orders have to go through you for tracking, even if you don’t have the authority to actually sign them. Let the Finance team know as well so that they can be copying you in on requests and making sure that the process is adhered to. They have no interest in receiving invoices that can’t be paid or getting the company into debt with inappropriate suppliers so they will be on your side! Read more here:
Pin for later reading:
Risk Identification: How to Do It
This article is part seven of my look into project risk management, and today the topic is project risk identification.
Read part 1 here: An introduction to risk management
Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)
Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)
Read part 4 here: Tailoring Risk Management
Read part 5 here: Planning Risk Management
Read part 6 here: The Risk Management Plan
Identify Risks is the second process in the Risk Management Knowledge Area. It’s where we work out what risks might befell the project.
In the process we look for overall project risk and also individual project risks – things that might affect one particular area of the project.
Typically, risk identification is done at the beginning of the project to work out what existing risks there are facing the project. However, it should be an ongoing activity, and you’ll revisit it from time to time during the project. Especially as you start to spend the risk budget or work out the cost of risk management activities – I think risk identification and management tends to spawn new risks. Perhaps that’s just because you get better at spotting them once you get started!
There are loads of inputs to this process.
The project management plan has lots of areas that could give you useful information for the risk identification exercise including the requirements management plan because that might reference particular at risk deliverables.
The schedule management plan probably talks about areas of the schedule that aren’t yet fully known, and that is another area of risk.
The cost management plan may identify budget areas that haven’t been fully costed or understood, or areas of contingency that might warrant raising a risk to keep them on the radar. Cost estimates are a project document that might also be useful, because the cost may be expressed as a range and that implies a risk to the budget as you don’t know what the cost is going to be.
And so on.
Tools and Techniques
There are also quite a lot of tools and techniques, although most of them will be familiar, I’m sure:
The data analysis you might want to do could include root cause analysis to uncover the underlying reasons for a risk – because knowing those will help you develop a better action plan.
You could also do a SWOT analysis, or look back on previous SWOT analyses. We used to do these annually as part of the department’s strategic planning, and there were often useful overarching risks in there that would translate to a project.
The end result of this process is the risk register. The risk register will include the initial risk responses if you already know what it is you are going to do.
There’s also the beginnings of the risk report and the updates you do to various project documents like the assumptions log, issue log and the lessons learned register – if you find anything worth putting in those.
Who gets involved?
Pretty much anyone who is working on the project can get involved in risk identification. That includes you as the project manager, the sponsor, team members, the risk management team from your company if you have one, any other subject matter experts, customers and end users… basically anyone who has any interest or influence over the project or knows anything about the work you are doing.
Risk identification is everyone’s job. Set that expectation at the beginning of the project and you’ll be fine!
Next time I’ll look at qualitative risk analysis – in other words, what to do with those risks now you’ve identified them.
Pin for later reading:
Benefits management: I wish we spent more time on this as I think it would help the wider project management community deliver more successfully. We’d know what success looked like, for a start. And we would hopefully work on fewer vanity projects because they would be weeded out – only projects with a decent return on investment (whatever that means to you and however you measure ‘return’) would get started… and hopefully completed.
A benefits dependency map is an easy thing to create to bring some sense of clarity to the benefits you see on a project.
This infographic gives you the headlines: it’s all about linking project objectives through to deliverables and then intermediate and end benefits. Then you can easily see how the project is going to achieve that return the business case talks about.
And if it isn’t clear, you’ve got time to do something about it before realising the project isn’t going to deliver the benefits you expected. Tweak the objectives, change the deliverables – do something to bring the project back in line.