The NOSE

Software Planning Demystified

Most large enterprises struggle with project management. Software projects can be even more of a challenge because they require an interdisciplinary view that balances the perspective of technology, business, and customer. As our portfolio management office starts to mature I thought I would write a series of postings ("annals of project management") on lessons learned and lessons still being learned in our organization.

Scott Berkun's The Art of Project Management is one of the best books in the field. His "Software Planning Demystified" diagram is an "insanely simple but handy view of planning".

Berkun's diagram is an insanely simple view of planning and I will keep coming back to it in future postings. Simple ideas are powerful but they require repetition and re-enforcement if they are to stick. Using Berkun's diagram as a starting point, I will make two assertions about the software development process:

• A necessary though not sufficient condition for project success is that everyone in the organization, business and technology, should have the same understanding of how the process works: what are the boundaries of each step? what are the associated artifacts or planning documents associated with each step? who has requirements authority (i.e who is the decider); who has design authority? who has technical authority? who has budget authority?
• Projects are more than scope, schedule, and budget. They have to be navigated on a sea of constant tension and negotiation between business and technology. In complex projects the same wave can either propel a project forward or sink it entirely.

Project Management and Portfolio Management at MNSCU

It's been less than a year since we created a Portfolio Management Office from scratch at Minnesota State Colleges and Universities. Here is a brief report on our experience, appearing as an article ("Order from Chaos") in EDTECH Magazine.

Portfolio and Project Management

There are numerous definitions of portfolio vs project management. Here is how I think about the distinction.

My organization recently launched a project management office (PMO) and we are learning something new every day. The right side of the diagram is about project execution: the core set of skills and discipline an organization needs to deliver projects well. The left  side of the diagram is about project selection and prioritization: the mechanism by which the right  projects appear on the doorstep of the PMO.

Portfolio management unites the two by ensuring that the "right" projects are selected and then those projects are delivered "well". Portfolio management presupposes ongoing assessment of every project from suggestion to inception and then to completion. The concept is simple. Is it easy to achieve? Not by any means.

Chandler: What Went Wrong?

Announced with great fanfare in 2002 as the "Microsoft Exchange killer", Chandler promised to a "revolutionary" open source personal information manager.

Chandler's brainchild Mitch Kapor provided an initial $5 million. The Mellon Foundation got on the bandwagon by providing $1.6 Million and a consortium of 25 Universities comprising the "Common Solutions Group" threw in another $1.25 Million.

Many moons and millions later we have at best a "pretty buggy and incomplete calendar application that's not very impressive compared to the 58 me-too Web 2.0 calendars that came out last year, each of which was developed by two college kids in their spare time, one of whom really just drew mascots....Chandler doesn't even have a mascot." (Joel Spolsky, Joel on Software).

What went wrong?

Joel Spolsky takes a look at Chandler in his review of Scott Rosenberg's Dreaming in Code. A MUST READ (Spolsky's blog posting and Rosenberg's book) for understanding the pitfalls in software development, project management, and possibly life itself.

Drinking the Project Management Kool Aid

We have drunk the Project Management Kool-Aid and are trying to get our PMO (Project Management Office) off the ground. A recent article in CIO Magazine ("When Failure Is Not An Option") describes A.G. Edwards' implementation journey.

Some key ideas from the article which are germane for us:

• "Project management is the number-one success factor for getting anything done in an organization. A firm's ability to execute its strategy lies within its ability to manage projects." Sam Lawler, director of GlassHouse Technologies' project management practice.
• "A PMO or a formal project management methodology (such as PMI or ITIL) doesn't guarantee success."
• "Projects remain challenged for two reasons. First, implementing formal methodologies requires a change management effort not just in IT but across the business. Second, PMOs often become minibureaucracies that fail to address the problems that dog projects, such as a lack of shared accountability between functional and project managers."

The most interesting aspect of A.G. Edwards' approach is their emphasis on establishing a standard plan framework, or a consistent and repeatable set of steps that govern all projects: "The framework lists 25 activities for managers to track during a project's lifecycle, such as developing architecture specifications, performing requirements analysis and building test plans."