Green Shoots and Killing Frosts

What’s the PMO for?

Reading some articles about PMOs and thinking over the “why” questions I’ve asked senior leaders about PMOs they were in the midst of creating, I was struck by how no one seems to be able to articulate the value of a PMO.  This is particularly strange when you consider the cost they impose on the organization. Not just headcount, but headcount empowered to demand things from other resources.  PMOs are a bureaucracy force multiplier.

So why do this?  I think there are several reasons some of which are ok, others which are bad and some which are comical.

Support for a Portfolio Management Process.  You want to review your in flight projects so that you can make tradeoffs if necessary, kill or fix problem projects before they waste too much money and impose basic controls on your business around cost and delivery on commitments.  So you try and you quickly realize that after you authorize a project you don’t have a project-centric view of your investments.  Enter the PM as score keeper.

Keeping different organizations in synch.  This goes back to engineering program management.  This organizational style put a man on the moon and launched Skylab.  It built the first atomic bomb and Three Mile Island.  (Total aside – the 70s were a disaster from front to back – Apollo 13, Watergate, Skylab, Three Mile Island, the Northeast blackout, the collapse of the Hartford  Civic Center – just to name a few things).  The idea was that a Program Manager with dictatorial powers would tell all the different teams what to do and bring projects in on time and on budget.  The modern version has functional PMs who nag and escalate, but the intent is the same – coordinating teams with different objectives and operating norms.  The growth of the Internet has exacerbated the problem of multiple organizations involved in a projects by creating an expectation of instantaneous access to information which in the past was accessed by a call center associate looking things up in different systems.  Now you’ve got to synch those teams up to deliver an automated solution.

Projects need to stop failing. When projects keep failing, organizations turn to a PMO to impose structure  and fix the problem.  If the projects are failing because of a lack of coordination this might not be a bad call.  Too often though it’s because some of the delivery people aren’t very good at their jobs.  The PMO, particularly with functional organizations, enables a lack of accountability or worse yet because of a lack of understanding of the underlying processes puts the accountability on the wrong people.  The PMO also drives consistency of process and documentation.  Often, PMs are poorly qualified to determine what each functional area needs to provide as documentation.

So what to do about a lack of information on your poorly-coordinated, failing projects?  Honestly, a PMO structure might be just the band-aid you need to stop the bleeding right now, but longer term the enterprise would be better served by moving towards a SOA system environment, agile development and a focus on workflow and knowledge management in governance tools.  A business that adopts these methods is better able to implement smaller projects with easier to measure payback.  PMOs can stifle the move towards these processes by hiding the cost of the PMO process and creating the illusion of success.

 

Bibliography

How To Make a PMO Work for You

Justification for Creating and Maintaining a PMO - A Proposal to Consider!

Setting the Standard

The Sound of One Hand Waving

I just got my Google Wave invitation.  I need to invite some people.  I think there’s a word for collaborating by yourself.

OK, so now what?

I’ve got Eclipse and R working together, R and MySQL working together and Eclipse and MySQL working together.

Enterprise vs Business Technology Approaches

Clearly yesterday I was frustrated by an 'Enterprise' project which was missing milestones.  Here's some background on my frustration with concept of the Enterprise initiative. The Enterprise label is routinely applied to projects which have long delivery horizons and poorly understood payback

Enterprise approaches are technology focused.  Business Technology approaches are problem-oriented.  With enterprise you're looking to the software to provide your discipline and the business model.  I was involved in an Oracle implementation which was routinely described as a check on the business' flawed control processes.  In other words, they were outsourcing their management process to Oracle.  That's hyperbole, but the way the management team clung to Oracle was like an addict to his 12-step program.

Business Technology, by contrast, tends to throw technology fixes at short-term problems without a long-term plan.  It can be very flexible, but it can also lead to business processes that would never have been implemented with a clearer approach because it tends to treat symptoms rather than causes.

Determining the right mix of these is the IT version of the political science question of determining the correct level of subsidiarity: which decisions are best left locally, which need to be at the center.

"Enterprise" means never having to say you're done

This has been one of those days where I am absolutely convinced that if you can't put together a deliverable result in 3 months the project ought to be canceled.

R and Eclipse

I finally got R and Eclipse to work together using the StatET.

Agile: Learn faster by failing faster

Evolution works not by leap, but by small steps, many of them bad ones and many indifferent. For a project team, a small steps approach also means not blowing the entire budget when the project is off track. This is the essence of Agile methodologies.

To make this work, a development team has to streamline its processes.  You have to get iterations in front of users quickly.  To quote a guy I once worked with "We know we're going to fail a bunch of times and we learn something each time.  Instead of pretending we're going to get it right, maybe we should try to fail faster."

Failing doesn't mean that the software doesn't work.  Sometimes it means that the software doesn't improve the process.  Sometimes this is because the customer got the answer wrong, sometimes it means they got the question wrong.  Sometimes it means there are implicit requirements that no one realized were there.

And while this might seem to contradict the notion of 'potentially shippable software each iteration", it needn't.  What your really doing is managing expectations.

Now getting your investment committee to buy into your slogan of 'Speed to failure' is the real trick.

Waterfall: Let me break it down for you - Part I Scope

Waterfall is about breaking up the development process, getting everyone to sign off on each phase and validating that each phase is consistent with the last one.  It's all about no surprises, hitting the date, the budget and the agreed scope and making sure that everyone is bought in every step of the way.

It tends to be 'high ceremony' with visible sign-offs, review meetings and oversight boards.  Do it right and everything moves ahead like clockwork.  You know what costs what, who asked for what and no one can say they were not informed.  There is basically a three-step process in getting to final scope - budget, charter / high-level scope and requirements.   At a later date, I'm going to make a case for test cases as part of the scope process, but the model I'm going to highlight has the test cases so bound up into requirements that it's really not a different phase.

Step 1 is a preliminary scope and budget.  I know it's supposed to be a project charter, but realistically most organizations have a planning cycle and need to approve the budget before they charter a team to go off an start making something.  The need to budget something before you analyze it drives IT managers nuts.  They don't want to commit until they've done their design and analysis which comes after requirements are finalized and the business legitimately needs to plan for the investment and the returns in advance of the work.  Some of this is IT managers being whiners, some is a legitimate response to a history of bad faith on the part of business partners.

Step 2 is the charter.  This is a more detailed scope statement and theoretically an authorization to proceed.  In practice, the budget is the authorization.  In a well-functioning business, this is the confirmation that what everyone thought was the goal is in fact where the customer wants to go.  In less well-functioning organizations, this is another opportunity for a fight as IT looks over every word to make sure that in its collective understanding, the scope didn't change. There is a role in trial law called an appeals specialist.  This is the lawyer whose only role is to prepare the appeal in case of an adverse decision.  In the requirements phase, IT starts to take on this role.  In this scope phase IT prepares to argue against requirements in the requirement definition phase.

Step 3 - Requirements.   At this point the customer is forced to put his/her cards on the table in detail.  Again, if things are going well, IT and the customer are both making productive suggestions and the requirements are coming together within the planned level of effort.  The bad version is that specifications exceed what was understood in the scope.  The customer feels entitled and the IT team feels like they've been had.

The real question is what makes an organization handle this well and what makes it not handle it well.  In my experience the success or failure here is completely unrelated to the artifacts or the methodology and the same factors drive success in a waterfall or agile environment: do the customers and the delivery team have a shared goal and a mutual respect that will allow them to work through the difficult patches.  Form the right team and any process will work.  If everyone brings their lawyer persona to the requirement meeting, you're in deep trouble.   I'll return to team formation in some later posts, but the key point here is that the people and culture have more to do with success in software projects than any process or methodology.

Agile: The Revolt of the Programmers

Agile methodologies are about reasserting the primacy of the programmer.  They cut out the BAs, QA, PMs and all the overhead associated with contemporary project management.  Designed by programmers they put the programmer and the customer together, force test discipline and try to keep the bureaucracy at bay.

If you've been a manager for a while, your first reaction to Agile methodology is to recoil in horror.  The main reason is probably that you've been a manager too long.  The second reason is that Agile methodologies emphasize quality over schedules, budgets and even defined scope (in other words everything that you're tasked to manage).

Waterfall methodologies are essentially Taylorism for development.  Break things down into increasingly simple tasks and measure performance. Something went wrong on the last project? Add an artifact and make sure a manager approves it. These methodologies are designed to turn the programmer from a craftsman to an industrial worker - ideally in another country.  The problem is that programmers don't just write code. They design your UI, they have a deep understanding of the business logic and they often help design your work flow.

In some posts down the road I'm going to discuss how to turn coding into a commodity and outsource as painlessly as possible for those who take the 'our-key-competency-is-not-managing-code' path.  I'm also going to discuss how to embrace agile development as a strategic capabilty.  The key difference between the two is whether you can see your programmers eventually being part of your business leadership or if you'ld just as soon not have them around.

Having a Strategy Means Making a Choice

In one of my undergraduate finance courses, a professor introduced us to the notion of arbitrage.  The idea was that sometimes there was a market anomaly which created an opportunity to sell in one market and buy in another and make money without incurring any additional risk.  He also said that in real life it doesn't happen - at least not to the likes of us.

A lot of high finance is the practice of looking for arbitrage.  A lot of people think strategy is the same thing.  In both cases, if you find you can improve your position with no cost it probably means you've been screwing up for quite a while.