Jobs, Projects, or Teams?

Posted by Robert Merrill on September 18, 2013 under Change Leadership, Projects | Read the First Comment

I just read a really interesting article, “Rethinking the Decision Factory,” by Roger Martin, Dean of the University of Toronto business school, on Harvard Business Review (if you don’t follow @HarvardBiz, I suggest it).

When People are Jobs in a Project world

I understand Martin’s main point to be that most businesses think in terms of Jobs, namely sets of responsibilities and tasks with no definite beginning and end. (This is “Job” as in “Position,” not “Job” as in e.g. a print run). But the essential unit of knowledge work isn’t the Job, it’s the Project. Because what makes Projects is beginnings and endings, and some sense in which no two are alike. I think Martin is saying this is a mismatch between the nature of the work and how we organize and (more importantly) think about people.

Martin says there are two downsides.

  1. First, it’s difficult to get the right people on project teams because of the job-centric organizational structure.
  2. Second, it’s difficult to get knowledge workers to share information, or refine what they do that really is more or less repeatable into heuristics (patterns) or algorithms (formulas), because that undermines their Job and therefore leaves them vulnerable in the next round of layoffs. Further, Martin says, the “next round of layoffs” is inevitable, precisely because of the inefficiency and sluggishness of the job-centric organization.

(As an aside, I’ve seen this to be especially true of the specialist and support roles in software shops, specifically project managers and business analysts. The harder it is for senior management to understand what they do—at least programmers “type”—and the more expensive they are, the more likely they are to get shown the door).

Solution: The Project-Based Organization?

What Martin suggests is the Project-based organization, in which a person’s “job description” becomes “execute whatever project we give you next.” As a pattern, he suggests the major services firms such as Accenture and McKinsey. As an example, Martin takes through a year-in-the-life of a junior marketer at Proctor & Gamble, whose Global Business Services unit is considered by Martin to be the vanguard of the new way.

At this point I grow a bit nervous, for three reasons:

  1. Do we really want to pattern ourselves after Accenture and McKinsey? As my colleague Larry McManis recently blogged, “Businesses and Consultants Get an F” for their rate of failed change initiatives, IT projects (tech-enabled business change), and mergers & acquisitions. So I’m not sure that the big consulting firms are who we want to imitate, unless that’s the business we’re also in.
  2. I’m also nervous about the Project as the organizing principle. Projects may have a definite Begin and End (although even that’s questionable), but many seem to have a rather fuzzy definition of Done, or Scope, if you prefer. Projects seem to consist of a somewhat tangled set of outcomes, some of which are clearly essential, others of which are clearly not worth the effort, and a lot more that are in between. And a lot of this no one really grasps until we’re well into them. As much as we try to contain them with gates and sign-offs and other levees, Projects, like rivers, are invaluable but not always cooperative.
  3. Finally, I’m nervous about the “interchangeable-resource” view of people and its ugly stepchild, the multiple-project “resource” allocation. It seems we would rather have fully utilized “resources” and slow teams.

I’ve come to believe that the engine of project productivity isn’t the individual, it’s the jelled, cross-functional team. These take time to form, and have a productivity that’s so much higher than the sum of the parts, maybe 3x, that it seems a shame to break them up at the end of every project.

A Cross-Functional-Team-Based Organizational Adaptability Factory?

What if knowledge work is really an organizational-change factory, not a decision factory? And the central organizing principle isn’t the project, it’s the cross-functional team? And the best way to think about the work itself is as a set of never-ending queues of business forces, constraints, and opportunities, and response concepts, feeding each project team, and resulting in steady streams of (often technology-enabled) organizational adaptations?

I’m no B-school dean, but this is after all the Internet. Food for thought, I hope.

Templates, Reuse, and the Rule of Three

Posted by Robert Merrill on August 19, 2013 under Projects, Tech Tips | Be the First to Comment

I just read Three Ways to Improve Your PMO (Project Management Office) Today. They are:

  1. Get Leadership Involved
  2. Find Templates
  3. Promote the PMO

By “Templates,” Brad Egeland means “project schedule shells, project planning documents, and test cases,” for example. Reuse is good, right? At least in my business (software), reuse of high-quality materials is the biggest productivity multiplier there is—around 3×.

First, Do No Harm

So why did I cringe a little at “Find Templates?” The dirty little secret of reuse has to do with quality. Read more of this article »

Dog Bites Man, Again

Posted by Robert Merrill on November 26, 2012 under 100 Words, Projects | Be the First to Comment

I think I know a fair bit about software project failures, at least small ones. My professional passion is to prevent them, and I’ve been mostly successful.

I learned about this latest one, “What Went Wrong? US Airforce blows $1B on failed enterprise software,” because of a lively discussion on the IIBA® (International Institute of Business Analysis®) LinkedIn group. At last count, there were 60 comments by 20 or so different people, most (including me) writing from general experiences and knowledge. The protagonists—Oracle, Computer Sciences Corporation (CSC), and the Project Management Office (PMO) for the Expeditionary Combat Support System (ECSS)—are being predictably guarded, but here are the facts, as near as I can tell:

  • The just-canceled Air Force ECSS was one of nine ERP projects underway in the Department of Defense,
  • Six of the nine are behind schedule by 2 to 12 years,
  • Five of the nine are over budget by $530M to $2.4B,
  • The canceled Air Force ECSS project was launched in 2005, with a total life-cycle budget for 2004-2027 of $3B, and projected savings of $13B. It was expected to replace 240(!) existing systems,
  • Oracle won the “firm-fixed price” software bid at $89M,
  • CSC was selected as the system integrator; they were given a stop-work order in September 2011, and their contract canceled in May 2012, after being paid $527M by the Air Force,
  • The General Accounting Office (GAO, re-branded as the Government Accountability Office in 2004) had already reviewed four of the nine and requested tighter controls, mostly in the areas of cost and schedule estimation and planning, and
  • At the time it was shut down, pilot deployments had been made in two of four functional areas, but with “known deficiencies and work-arounds.” The total expected lifetime cost had risen to $5.2B, and the completion date moved to 2016 (or 2020, depending on the source).

To put things in perspective, the USAF’s 2012 budget is about $165B. For a company with a $10M operating and capital budget, an ECSS-sized goof would pour about $60K down the drain. Smugness? Time to lose it. I’ve been involved in one of those, and that in the years since I understood software project failure.

You know what’s really sad though? The story of ECSS and its cancellation didn’t surprise me. As the saying goes, “Dog bites man? That’s not news. Man bites dog? Now that’s news!”

It doesn’t seem to have surprised very many other people, either. There’s little suggestion in the various articles about ECSS that the process is more than a tad broken, much less that there’s a scandal brewing. A year ago, IT project failure expert Michael Krigsman was philosophical. “The size and scope of government IT projects is staggering and failure rates are high. Then you take massive projects combined with the intense politics and information silos in the government…” He also mentioned the politics of dealing with various enterprise vendors during the procurement phase. But recently, Krigsman’s resignation had turned to frustrated anger. “Why did it take the [Air Force] $1 billion and almost 10 years to realize this project is a disaster? What kind of planning process accepts a billion dollars of waste?”

“The planning process for DOD ERP projects,” as it turns out. I just found a 2011 report, “Assessment of DOD ERP Systems,” by the Institute for Defense Analysis which, at 145 pages, I’ve no time to digest before press time. Plus, I have client work to do.

Now, neither you nor I will probably ever be responsible for a project anywhere near this big. But I’ve decided to devote a newsletter and blog post series to it, anyway.

  • Even little software projects still fail too often.
  • I think I understand software project failure, which means it’s time to start over with a clean sheet of paper so I can learn something.
  • We learn deep lessons best from our own pain, and second best from outsized stories like ECSS (think “Excess”), so I think you’ll learn something, too.

I’ll do the hard work of wading through the 145 page report from the Institute for Defense Analysis and that GAO report (did you click on that link earlier? I dare you!) so you don’t have to. Plus, you’ve already paid your $3 tuition.

If you need a weekly email reminder, subscribe at the upper left.