I consult, write, and speak on running better technology businesses (tech firms and IT captives) and the things that make it possible: good governance behaviors (activist investing in IT), what matters most (results, not effort), how we organize (restructure from the technologically abstract to the business concrete), how we execute and manage (replacing industrial with professional), how we plan (debunking the myth of control), and how we pay the bills (capital-intensive financing and budgeting in an agile world). I am increasingly interested in robustness over optimization.

I work for ThoughtWorks, the global leader in software delivery and consulting.

Monday, October 13, 2008

The Agile PMO - Real Time Metrics and Visibility Webinar - 5 November

There’s a lot riding on IT in the current economic climate. In tight times, businesses rely on efficiency, and IT investments will be expected to create a lot of that efficiency. But while IT assets may help the business tighten up, IT execution must also tighten up to match the times.

That doesn’t mean IT projects have to execute flawlessly. They never will, as there will always be situations and events that challenge even the most experienced of teams. What it does mean is that the people responsible for IT projects will need to make well-informed decisions throughout the life of a project. That requires current, accurate and clear information about what’s actually happening in eah project.

IT doesn’t excel at this today. The failure rate of IT projects has been discussed for decades. Yet the most important IT initiatives that are subject to the greatest scrutiny still crater suddenly late in their lifecycles, much to the surprise of their executive sponsors. This exposes the very wide divide between what the PMOs need to know to oversight a portfolio (such as total time spent, features complete and functional QA results) and the indicators that the PMs use to manage projects day-to-day (such as technical task orders, defect counts and high-priority issue lists.) This gap also means that the status data that the PMOs eventually get is late and stale.

What this all means is that PMs are doing double duty, executives are getting blindsided, and PMOs are caught in the middle unable to satisfy either. The collective frustration by all parties is unfortunate, but it may also be little more than a tragic sideline. Capital is scarce and increasingly impatient, and IT will find it even more so if its business partners have little confidence that IT can deliver. Historically, executives have felt backed into a corner when an IT project fails, given little choice other than bailing out a project that has suddenly and surprisingly redlined. But as we're seeing in the global economy right now, historical patterns no longer apply.

Using requirements - not abstractions - as gatekeepers. What does it mean to complete business requirements and not just tasks, and why does this distinction matter?

Transparency. How can the PMO get unambiguous line-of-sight into what’s happening on the ground across the portfolio, both functionally and technically?

Metrics. We need information, not dispirit data points. What is signal, and what is just noise coming out of a project? How does Agile cut through the noise?

Collection. We need to collect project data efficiently, otherwise our projects will suffer under the weight of data generation (or simply not report it). How does Agile align with PMO needs so that collecting status data is not a burden to project teams?