Project portfolio management software is one of the hot new trends in project execution. In recent years, the tools have become much more powerful, they have integrated powerful new functionality and--with SaaS models--they have become much more accessible. The promise of PPM has been out there for more than a decade, but finally it’s becoming reality. I can’t help but wonder what the next big thing is for these tools, or at least for the data that they contain. This month’s theme of business intelligence really got me thinking that there could be some exciting things possible if we combine a PPM database with a BI tool.
That’s what I want to address in this article, looking at ways that we can create a decision-support function for project managers through these two approaches--and how that might improve the quality of project execution.
A simple exampleSuppose that we have just completed the project schedule for a business-critical initiative. We know that the timelines are tight, and it’s important that we hit the deadline. Clearly we are going to manage this project based on doing everything that we can to protect the critical path, but where are our potential problem areas? Not every task on the critical path is a potential time bomb, and not every potential time bomb is on the critical path. We need a way to flag those tasks that are the most likely to be difficult for us, but is that simply a case of the PM’s judgment or is there something else that we can leverage to provide some decision support?
Our PPM tool has a huge amount of information in it about historic tasks and how we performed relative to how we were expected to perform. From a PPM perspective, that information is used to identify the performance on an individual project and calculate the implications on that initiative. But ultimately, it is simply data in a database--and if we can use that data in a different way, why wouldn’t we? PPM tools tend to capture a lot of data elements about tasks--the type of work, the department, the resources, etc., and the tools will allow for additional data tags to be added so we can also capture information on anything that we consider relevant (perhaps a 1-5 scale of complexity, information on the technologies involved--literally anything that we feel may add value to our view of the project).
These additional fields will add a small amount of complexity when we are building our plans, and if we use a numeric scale then we need to define the values (or have them automatically calculated based on other criteria), but the additional work is not excessive. More importantly, we need to be consistent in capturing this data across all projects so that we have as many data points as possible when it comes to applying BI processes. We may also want to consider different templates for our tasks--technical tasks capture different data values than business-related tasks, for example.
Leveraging the dataOnce we have key task-level information captured, then we can start looking at what that information can tell us--and that’s where the BI element kicks in. We need to be careful here, because business intelligence is not a magic bullet--we can’t just throw a bunch of data at it and have it tell us what we need to do. Rather, we have to use the BI tool to ask the right questions of the data and then we have to interpret the results.
Let’s go back to our original example of a just-completed plan. Depending on the PPM solution that we are using, we may be able to do an analysis of the highest-risk tasks within the current project based solely on that data--perhaps the combination of high-risk tasks and low-experience resources that are on (or within) a week of the critical path. That’s helpful, but it’s not a particularly meaningful analysis; a good project manager likely knew that those were the high risk tasks anyway.
However, if we can compare our current project with what actually happened on previous projects, then we can start to see some tremendous value add. We can use the BI tool to help identify similar tasks in the past and compare planned duration with actual duration to see whether that identifies some potential problems that we might not otherwise have come up with. Perhaps a task that is further away from the critical path, or that appears to be low risk based on the data elements that we have captured--but where history suggests we have problems.
This isn’t an exact science; there may be any number of reasons why a comparable task had problems on previous initiatives that are unique to those projects. But a business intelligence-based analysis can at least identify areas where the PM should spend a little more time than they might otherwise have done. The PM will then need to use his or her judgment to determine whether there is a reason for concern, or at least be prepared to take action earlier if the task shows signs of getting delayed.
Business intelligence information can also help a project manager identify the best course of action to take in the event that problems occur. Suppose that our example project is falling behind--delays are occurring on the critical path and it doesn’t look like things will recover on their own. Ordinarily, the project manager will look at alternatives, consult with team members and decide on how best to proceed--moving tasks around, adding resources, overlapping tasks that should be dependencies, etc. That analysis is still required in an environment with BI, but the PM will have access to the answers to a number of key questions:
- On past projects, what type of tasks responded best to additional resources?
- Of the resources that we have access to, is there one who has had a bigger impact in recovering tasks when they are assigned as an additional resource?
- Do we generally see more success from overlapping dependent tasks or adding resources?
- How big a recovery can we expect to get on a single task?
- Is there generally a better outcome from adding resources to separate work streams, or should we focus the extra resources in one particular area?
None of this information is a replacement for the ability of the PM to make good decisions, but the information can provide a strong support function for those decisions--helping the PM to choose the right options and reducing the risks associated with recovery-type actions. Of course BI can also support any other project decision that the PM needs to make, not just these recovery-type situations--impact of change requests, work estimation, forecasts and projections, etc.
ConclusionsPPM tools are becoming more and more powerful, and they are capable of presenting project data in a number of different ways. However, while they have the ability to store historic information, they are geared around the management of current initiatives--that is what they do well. By taking the data that those applications contain and making it available to a BI tool, we can create a whole new perspective on our projects that can help us to make the right decisions and provide accurate analysis.
In some ways, this creates more work for the PM because it provides additional information that requires interpretation. But any PM will accept the tradeoff of a little more work for a lot more confidence in their decisions. This approach will also take some time to implement as organizations will need to build up the data history, and of course there will be a small amount of additional work in entering and maintaining that data. However, none of that is an unreasonable amount of work--and the benefits can be significant.
