Work Management and the Need to Jump Through Hoops
From the Strategic Project Management Blog
by Ty Kiisel
If you've ever been to the circus you've seen what I'm about to describe. A trainer walks into the center ring followed by several dogs who proceed to run up skinny ramps, up and down teeter-totters and jump through hoops. Unfortunately, the circus isn't the only place I've seen this.
I was talking with a colleague the other day, and she suggested that 25-55 percent of most project requirements are unnecessary. In my opinion, she is in a position to know. Her job is to consult with project leaders and project management vendors all over the world. I must admit, although I personally believed that many project managers are compelled to force their teams to jump through a lot of hoops for "process" sake, I didn't think it was that bad.
I myself have been forced to jump through what appeared to be meaningless hoops from time to time. What's more, unlike the dogs at the circus, the hoops I was forced to jump through weren't even for the entertainment of others (at least I hope they weren't). I wonder how many of us have lost our way in the morass of process and lost track of the fact that projects are the vehicle we use to accomplish something. The processes we use should serve to make the complicated world of projects easier to navigate, not more convoluted and complicated.
I have often felt like we implement complicated processes for the sake of process—when much of the work we do doesn't require such a heavy burden. Of course there are times when formal processes and governance are required for project success. However, it is incumbent upon us as project leaders to weigh the value of process against the value of providing value to our organizations quickly and often.
I suggest we consider a more flexible leadership approach. A simple project, that consists of a dozen or so simple steps in a "to do" list, neither diminishes the value of the project nor the skills of the project leader. In my opinion, the simplest solution that produces the most value is often the best. And, the project leader who recognizes that is worth his or her weight in gold.
Posted on: February 01, 2011 11:23 AM |
Permalink
Comments (8)
Please login or join to subscribe to this item
 | sheba |
I couldn't agree more, but with one small proviso.
I have been in the position where an account has required, (in some instances demanded) that an overly complex process must be completed. Often this process is not only so complex it is beyond the understanding of the client/customer but also inaccurate if not simply incorrect and misleading. For example in one situation we, (the PM community) were required to produce Earned Value charts and stats for a client. The client immediately turned this page over in the monthly report, some jokingly looked at it upside down. The information in the EV chart was incorrect and misleading as it did not accurately reflect changes to the project, (unless much effort was spent starting the EV analysis from scratch - a desk exercise not worth the time in the value it provided). Finally because of the time this process took to complete the PM's spent much less time 'on the floor' managing the project.
Now the proviso...
Sometimes the process and tools a PM has at his or her disposal can be used to protect the PM in difficult situations, (either internally or with the client). One of the best pieces of advice from an experienced PM I have ever been given was - "use the tool to protect yourselves".
Peter Craig
Technical Leader| Yorkshire Water
Bradford, United Kingdom
An interesting and thought-provoking article. The PM community in my organisation is very process-oriented - indeed one of my personal responsibilities is to manage and promote standard use of the PM process ''hoops''. The underlying philosophy is "If you follow these processes, regardless of the scale or complexity of the project, you know you''ll spot any problems early, and so be able to react to them".
However, inflexible use of the processes must mean that small or simple projects incur unnecessary cost and time, to the frustration of their project managers (and customers).
The problem is - how to ''prove'' that it''s safe for projects to use slimmed-down processes, or indeed drop unnecessary ones? We have just started to use a technique (another process!) where during project initiation, we classify a project as ''simple'' or ''complex'' - based loosely on the four types, Paint By Numbers, Quest, Movie or Fog. ''Simple'' projects are allowed to drop or reduce some governance processes. Time will tell how successful (and safe) this is!
Daria Adams
Enterprise Project Management and Oversite| US Department of Education/Federal Student Aid
Reston, Va, United States
Great article!
Peter - we are implementing something similar to your project classification. We have three project types: simple, standard, and complex. These are determined based on risk factors such as cost, scope (enterprise wide project vs business unit level project), and experience with similar types of projects. Governance and documentation requirements are adjusted according to the classification.
| Linda |
Daria - How are you defining: simple, standard, and complex and how do the definitions compare with small, medium and large projects?
Michael Frisce
Sr Business Manager| AT&T
San Antonio, Tx, United States
You must tailor your process to fit the scale of the project. Utilize small, med and large to drive process admin while you continue to look for opportunities to drive overhead/requirements out of the process to support core activities that bring value.
Ty Kiisel
Manager Social Outreach| AtTask
Lehi, Ut, United States
Thank you everyone for participating in the dialog. This is a great discussion.
Peter Craig
Technical Leader| Yorkshire Water
Bradford, United Kingdom
We used to score projects as small, medium or large with measures like project cost or numbers of customers affected. We''ve now moved to "Simple" or "Complex" based on the Risk in the project.
For example we implement a lot of asset replacement projects - upgrading the same piece of kit on, say, 500 sites. A long-running project, affecting many siites, and high cost, but it''s really just 500 small, simple projects combined for efficiency. Low Risk, so we use "Simple" processes.
Typical measures to classify whether "Simple" or "Complex" are things like ''Are we introducing technology that''s new to the company?'', ''Does it have an immoveable deadline?'', or ''Is the End Result of the project unknown?'' (e.g. a Foggy project).
Robin Goldsmith
President| Go Pro Management Inc.
Needham, Ma, United States
First, let me suggest that instead of calling these ''project requirements'' call them ''required project management procedures.'' In my experience, the term ''project requirements'' mainly refers to what the project is supposed to accomplish, not just the ways in which the project is supposed to be performed.
Second, considerable creep comes from well-intentioned but premature efforts to save time by excluding desired project results because someone (like a project manager, business analyst, or boss) with inadequate information presumes either the results are not needed or will not be able to be delivered with anticipated project time and resources. These are REAL business requirements and should be identified inclusively. Prioritization for implementation of the full set should come later. Problems arise because requirements which had been excluded invariably turn out to be needed and end up costing ten times as much or more to deliver in change mode.
Third, stating that 25-55 percent of said procedures are unnecessary for most projects does not necessarily give a clue as to which procedures are the 25-55 percent. If as I suspect it''s not the same procedures project after project, nothing is to be gained and there''s big illusory risk of focusing on the 25-55 percent figure.
Please Login/Register to leave a comment.
|
We are ready for any unforeseen event that may or may not occur.
- Dan Quayle
|
