Friday, September 28, 2012

Controlling PMO Cancer

The swarm of project coordinators and the meetings they demanded multiplied at a rate that would make E. coli blush. "Dependency, dependency, we must understand all dependencies!" they shrieked. Spawned by the CIOs need for centralized control - presumably as a means to minimize risk and get visibility - the PMO was in fact undermining progress.

The drag their efforts imposed on people doing real work was frustrating. Worse, it sapped valuable mind share and time. And soaked up budget (hey CFO, are you listening?).

Their methods destroyed accountability, too. This in turn raised the importance of the PMO's existence as a mediator. Who else was going to resolve, through endless meetings, interviews, inspections, PowerPoint, and revised project plans, the missed handoffs resulting from their meddling?

In unleashing this cancer, management failed to realize that the organization - as a complex system - was unmanageable this way. At a tiny fraction of the cost of bloated PMO, superior coordination can be achieved by using an agent model, not a centralized control model. Here's how.

Each team must follow a simple set of rules:
  • Publish your milestones, 
  • Negotiate milestones with your dependencies,
  • Trust the milestones of your dependencies in your own plans, 
  • By all means, make your milestones.
Autonomy, predictability and transparency inoculate against the PMO cancer. And guess where the leaders should focus? Enabling - not mandating, not demanding - predictability and transparency.

If your CIO is diving into the PMO rabbit hole, isn't it time for an intervention?

Wednesday, September 26, 2012

Fed Conflict of Interest Rules (OCI) Undermine Continuous Improvement

Federal procurement rules include a concept called Organizational Conflict of Interest (OCI), [FAR Subpart 9.5]. Intended to keep a level competitive playing field, one particular element of OCI is retrograde for software development work.

This element mandates that the group that specifies a solution cannot implement that solution. Yes, that is correct.  The team that invests in learning the problem domain, understanding the customer's problems and framing a solution must specify the solution yet cannot be involved in creating the solution.

This has negative implications in software construction. The team that specifies a solution has no accountability for the feasibility of that solution. Moreover, because they are never around when the solution is created, they never receive any feedback about what works and what doesn't. Their ability to recommend solutions is therefore questionable.

This runs counter to the idea of continuous improvement. This subverts the ideal of craftsmanship. It is the act of doing that teaches us what should be done. In the doing there is learning that cannot be accomplished without the experience of doing. And designers who don't do never experience the insights that lead to innovation. Andy Grove wrote eloquently about this as a national problem here.

It seems that in practice, the larger the problem the stronger the enforcement of these OCI provisions. Evidence the very lucrative Systems Engineering Technical Assistance (SETA) companies that study but never deliver. Could this be one of the reasons the federal government has such a horrible track record with large software projects?

Tuesday, September 25, 2012

Fractional People: Obsessive Focus on Resources Misses Value

The sight was surreal. Just over 100 cubicles housed the IT staff. Organized by the system they supported, several score workers leaned into their screens. Working intently and quietly, oblivious to the body parts of dozens of others around them. The head of an analyst here, the upper half of a tester there, a half PM was split bilaterally. Fractionals manned a third of the screens.

Good work doesn't get done this way. Yet, portfolio planning, budgeting, and project management often do. Project managers, overseers, and financial stakeholders spend countless hours tallying bodies. They believe their centralized model of headcount-control is efficient. They are helping the company by shifting people from one project to another, adding, removing, and defending the status quo.

But, this neurotically obsessive focus on "resources" minimizes effectiveness.
  • Treated as fractions, people doing real work lose purpose. A few hours on this, a few days on that, back to this again. No predictability, no consistency, and no opportunity to leverage experience to make a dramatic improvement.
  • Work gets organized and prioritized by the availability of the various fractions, 2/3 of a tester, 1/4 of pm, 1.6 developers. 
  • Controlling the fractions becomes an exalted position that begets more positions - it's time consuming, you know!
  • The numbers give "cost avoiders" the ready-made metrics they need for browbeating possibility into an expense line.
  • And sadly, all lose sight of the real goal, the result they are supposed to be working towards: creating value for constituents of the organization they inhabit.
They are lost in the weeds managing cost instead of managing the leading indicators of value. What they miss is that by focusing instead on value, the bean counting will sort itself out. And will do so with far less work, far less useless work, and more satisfaction all around. And more value delivered.

Thursday, September 20, 2012

The Myth of "Oversight" for Reducing Risk in IT

Information technology departments (IT) have a love affair with "oversight." Adopted as the panacea for controlling risk, the sad reality is that oversight costs organizations dearly in time and money. This might be worth the cost, except the common forms of IT oversight actually increase risk.

Oversight comes in different flavors. Sometimes masquerading as governance,more often it's implemented as Enterprise Architecture (EA),  Program/Project Management Office (PMO), or both. These efforts are started with the best of intentions, but the consequences are costly:
  • At 10-20% of total organization size, oversight is not cheap. (see PMO Headcount Sizing). And it tends to grow. One CIO commented sagely "PMO's are a cancer; left unchecked they grow to choke the real work of the enterprise."
  • In addition, oversight adds a 20-50% hidden tax on the work overseen. Teams are forced to add staff and time to address the inappropriate, rigid methods, unproductive review meetings, redundant reporting, and excessive documentation imposed in the name of oversight. 
  • Moreover, oversight frequently raises non-issues to emergency status, causing teams to expend time and resources chasing phantoms just to stay in good stead.
  • Finally, excessive oversight checkpoints add wait states that cost real money. In one egregious example, a PM told me that 66% of his project budget was spent waiting for EA & PMO approvals.
In short, oversight can easily double the cost and time to complete work. Maybe this cost would make sense if oversight minimized risk. But as implemented in IT, oversight actually increases risk:
  • Contrary to popular belief, an outside, non-practitioner cannot spot risk by imposing method or by periodic inspection. Even a savvy practitioner will shy away from the responsibility of pronouncing project health, or finding project fault, by casual inspection. She knows that risk is best exposed and mitigated by, and while, doing the work.
  • Delays imposed by oversight transfer the risk from the program to the mission. And in some cases, not having a mission solution is riskier than any risk generated in creating a solution. For example, one federal agency has spent so long reviewing a project that the mission capability is literally months away from functional failure.
  • Oversight stifles innovation by its rigid adherence to "standards" - mindlessly sticking to the "way we know." Failure to keep pace with the knowledge gained by industry experience builds technical debt, a form of adding risk.
  • Finally, oversight leads to information hiding. The dirty secret is that teams tell "oversight" what it wants to hear to make them go away. Oversight then reports inaccurate information to decision makers and dependents. It may take months or even years, but eventually the disconnect between perception and reality will become obvious. And by then, the damage is more extensive, harder to contain, and mitigation far more costly.
Oversight may make organizations feel good. But as commonly implemented it pads cost, increases delivery time, and increases risk.

Superior risk reduction and efficiency can be achieved not by costly oversight, but by other means. I'll leave describing those other means for later.