The Biotech IT PMO 2.0

As a CIO, you have either made – or heard – recommendations to create an IT project management office. Perhaps you have implemented one, and your department is reaping the benefits of project planning, monitoring, and controlling. IT delivers its projects on time, on budget, and to spec. Congratulations! You and your IT PMO have put the foundation of consistent innovation in place.

Nevertheless, it is no more than a foundation. A PMO must…

For more, see the full article at CIO Review.

High performing project management orgs are more agile — PMI

The Project Management Institute’s latest “Pulse of the Profession” report just came out, and it’s full of provoking findings. It clarifies the benefits of high-performing project management, and it highlights what the top organizations do differently. By the way, the “PMI Pulse” is a nice complement to the McKinsey report on building capabilities I wrote on last week.

So what does it mean to your organization if it’s a project management top performer? It means that you deliver more value and waste fewer resources:

…these organizations meet original goals and business intent two-and-a-half times more often than those in low performing organizations (90 percent vs. 36 percent). High-performing organizations also waste about 13 times less money than low performers. — PMI Pulse, page 6

Did you know that these top performers used agile techniques more often than other organizations? This use of agile, iterative, and incremental methods drove better organizational agility. In turn, this better agility allows for faster and more effective responses to competitive, technological, regulatory, or other external challenges. PMI found that the most agile delivered against business, cost, and schedule goals between 20 to 50 percent better than the least agile. Agile also means better top and bottom lines: the PMI Pulse report references a MIT study that found agile firms grew revenue 37 percent faster than non-agile firms, while generating 30 percent better profitability.

To that end, PM College has greatly expanded it’s agile curriculum, from the basics, to an Agile Bootcamp, to negotiating Agile vs. Waterfall, to PMI Agile and ScrumMaster certification prep.

Agile principles have a been a lifesaver on a number of my projects and programs. If nothing else, an agile education gets you and your organization thinking and working the agile way…even before you implement any methodology at all.

Agile Mythbustin’ (RT @bobsarni, HT @brown_note)

Nice collection of agile “objection” answers, though I’d be a bit kinder to the resisters. Turn the right ones and they’re your strongest, most effective advocates. (RT @bobsarni, HT @brown_note) Agile Doesn’t Work For…: Ever run across these guys? People whose lack of experience or fear of change cause th… http://t.co/5CrFyFAn

Kaizen and Project Management

Last week I got a chance to tour the Mead Johnson manufacturing facilities here in Evansville, and I was struck by how firmly kaizen is embedded in the culture of our supply chain.   The plants are clean and tidy, with performance and safety metrics prominently displayed.  Improvement ideas are posted, the author(s) credited, and the results are made available to all.

I’ve always thought that PMs could better leverage kaizen thinking, especially when they’re IT PMs in a business that values continuous improvement.  Many methodologies are out there for kaizen-inspired product or project management.  These concepts are at the heart of agile, Six Sigma, lean, etc.  In fact, I’m using some principles now, like using 5S to organize the project portfolio.  I’m also planning to get key performance reporting visible to all.

What other approaches have you seen to introduce “project management with kaizen characteristics”?  In particular, I’d like to see what has worked to promote better IT/business understanding and alignment.

PMI and Agilests?

Cats and dogs, living together...

Cats and dogs, living together...

Greg Balestrero — CEO of the Project Management Institute — recently posted (here) on his experiences at the Scrum Gathering in Orlando.  In my experience, Greg and the PMI staff have been very eager to foster a better relationship among the various methodology camps.  Per Greg’s post,

[t]he intent of the visit was to bridge the gap between the Scrum Alliance and PMI. But I guess the real reason we attended was to dispel the myths that surround the PMBOK® Guide and Agile practice. There is a widely held opinion that the PMBOK® Guide and Agile don’t mix… they can’t be “shaken, nor stirred” together. 

Please read the post…it gives an interesting perspective on how to build alliances among disparate points of view and how to overcome misconceptions.

Using SCRUM with ASAP

Ron Stanton sent me a mail asking how SCRUM works with our implementation methodology — ASAP for Implementation. While SAP does have a SCRUM methodology that we use — SAPScrum — it is an internal approach used for solution development.  SAPScrum is pretty straight SCRUM, so there’s no mystery to it.

We just started a project to make ASAP more agile-friendly, we’re a little ways from publishing it. For now, below are a few general guidelines in using SCRUM in an ASAP environment.

  1. The first principle is to remember that the SAP solution(s) serves as the development platform or environment. It isn’t simply an application to which you’re integrating.
  2. Of course, a product backlog should be one of the outputs of the Blueprint phase. The product backlog should be mapped to the processes here (as part of identifying testing scenarios).
  3. Appropriate prioritization of the backlog is critical in an SAP environment. In particular, non-technical product owners often forget to include integration dependencies as one of the prioritization criteria.
  4. Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
  5. It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
  6. Most ASAP config/testing cycles are typically 2-4 weeks long, so one sprint:one config/test cycle is reasonable. If the project is especially large — with longer config/test cycles — then consider nesting sprints within those longer cycles.

Goals and the limits of self-organization

Thought-provoking post by Jurgen Appelo on the teleology of software projects (post here, check the perceptive comments too).  More properly, he points out that projects do not have a goal in and of themselves.  In his words, they don’t have intrinsic goals (other than self-preservation).

For me, this insight points to the limits of self-organization in initiatives.   IMO, without some degree of design — or extrinsic goals — a self-organized system (or pieces of that system) can get off the rails.  There is a tremendous amount of power in emergent-friendly systems — that’s what social media is all about.   For example, what emerges from Wikipedia is clearly emergent, but it has a explicit goal and with an extrinsic design model:

Wikipedia’s purpose is to act as an encyclopedia, a comprehensive written compendium that contains information on all branches of knowledge

Finding the proper balance between design and emergence is a fascinating topic.  In fact, my take is that this topic is the subtext of many of the arguments among methodology adherents — waterfall vs. agile. 

I’m always a bit leery of purist arguments.  In fact, I have a syncretist’s instinct to “square the circle”.  Perhaps what I’m looking for is something like Deng Xiaoping’s modifications to traditional Marxist dogma…   How about “Waterfall with Agile Characteristics”?

Follow

Get every new post delivered to your Inbox.

Join 11,914 other followers

%d bloggers like this: