Designing Projects

25 09, 07 23:06 Filed under: Work

Give a team a project and what will they do? Chances are much better than even that they will focus upon building the product, not their project. Some will insist upon a method for construction, but few will carefully consider the design of their project. Project design will be lost in the rush to fulfillment which will include gathering requirements, laying out work steps, mustering team members, and controlling execution.

The result is often an unmanagable effort supported by little more than hollow assumptions about the present and the future. Speculation masquerades as certainty. The effort proceeds until it encounters an unanticipated reality. Then what? Requirements are reconsidered, plans are redrafted, and the process is more-or-less repeated. Often, six times out of seven, expected results are not achieved.

The obvious strategies for resolving this difficulty include getting better at defining requirements, making better plans, and improving control of execution. Obvious and wrong, but not obviously wrong. Something is missing from the standard project execution strategy. This missing element is project design.

Designing in a project context is not the same as planning. Project planning focuses upon the steps between idea and end product. Project design considers the context within which idea might become product, while questioning both the idea and the product. Rather than gather requirements, project designers questions them.

Project designers questions requirements to find balance between initiating bright idea and resulting legacy effects, looking for useful variations outside the expected patterns of engagement.

We might aspire to satisfy ourselves and our clients by pulling a pre-packaged project design off some shelf, like some ready-to-eat meal. Will this project be lean cuisine or agile fare? Washed down with waterfall or wine? These are the wrong questions.

Fine meals, like fine projects, start with something other than gathering requirements. They start with deliberate design. Of course, the requirements for designing any project conflict and cannot be logically resolved. Perhaps this is why so many projects choose to just get to work, heading off in some direction, any familiar direction, rather than wrestle design dilemmas to ground.

Where does one learn project design? How does one, perhaps trained only in the traditions of project management and execution, stumble upon the principles of project design?

For the last decade or so, some have first encountered the fundamentals of project design by attending our Mastering Projects Workshop. Many enrolled thinking this to be a project management workshop. And I’m afraid that we unintentionally encouraged this misunderstanding. When the workshops started, people caught on that we were considering a different side of projects, one most had never stopped to consider. We were lacking, then, the descriptive term that might have better set expectations. No longer.

We are project designers. If you think design doesn’t make a difference, look around you. Most everything you see bears the marks of design. Some deliberate and fine. Others crude and inadvertant.

We see the same differences when we look at projects. The marks of deliberate, thoughtful design are obvious. The marks of inadvertent design even more so.

Where do you start to learn about designing projects? Attend our up-coming Mastering Projects Workshops in Spokane, Washington or Portland, Oregon. We think that if you engage in project work, and especially if you’ve found this work unsatisfying, this is absolutely essential training. If you and your clients are satisfied with a microwaveable methodology, God Bless You. You could make something better from scratch, at lower cost, with higher satisfaction. Let us show you how.

Here’s the link

Spokane, WA October 23-25, 2007
Portland, OR November 13-15, 2007

PureSchmaltz

Rendered Fat Content

Designing Projects

Good For A Goose