Analytics, Projects and Achieving Goals - Using PM3 to report on Agile Projects

Although everyone who is involved in IT would tell you that their primary focus is on achieving positive outcomes within their business I am increasingly coming to doubt it. If you were really focussed on goals you would identify what you want to achieve and how you would measure that at the outset. In my focus area of Business Intelligence, or analytics, you become only too aware that analytics are added on to most projects as an afterthought. They often measure an approximate measure to the real goal because it is easy to achieve.

Likewise, on the projects themselves, what I see is not a focus on outcomes but on activity. When running a PMO the main focus from most senior managers is on ensuring that projects initiate quickly and that there is activity visible to all from day 1. Later they will moan that much of that activity was inappropriate but at the time they want to see it.

I have long been an advocate of Agile approaches because of their focus on using scarce resources to achieve the maximum business benefit. As Agile becomes more popular I see it being increasingly misused with much of the trappings being adopted, but none of the core philosophy.

Part of the problem stems from the lack of common ground between agile proponents and senior management  (both IT and Business) who have not used it and confuse it with iterative prototype-based development and who like the structure that the waterfall seems to provide.

In a recent thread on the Agile Forum on LinkedIn, agile supporters were arguing that milestones and plans were not required as Agile teams should be self managing-it all sounds a bit like claiming that banks should be self regulating to me! I think we need to have project analytics, like business analytics, that focus on outcomes.

On a recent assignment I helped configure Bestoutcome’s PM3, a Goal Directed Project Management tool, to provide reporting back to senior management on agile projects. Having found previously that using MS Project plans with each iteration just being a time boxed straight line and the RAG status always being Green because we flex the scope to make time and budget, results in nothing but mistrust amongst those who do not get Agile. it seemed like a good opportunity to try and communicate better. So the projects still kept to time and budget, and the MS Project plans were still just start to finish straight lines, but now we could use the risk and issues log to drive the RAG status, and we could report along lines that made sense to senior management.

So, once more, I have to conclude that good analytics have to address the needs of the audience and have to focus on outcomes and not activity. This is as true of projects as it is of BAU business activity. Good analytics must be central to best practise; you are what you measure and report. Although everyone who is involved in IT would tell you that their primary focus is on achieving positive outcomes within their business, I am increasingly coming to doubt it. If you were really focussed on goals you would identify what you want to achieve and how you would measure that at the outset. In my focus area of Business Intelligence, or analytics, you become only too aware that analytics are added on to most projects as an afterthought. They often measure an approximate measure to the real goal because it easy to achieve.