cazh1: on Business, Information, and Technology

We continue to iterate on our PMO processes - managing too few resources and too many project requests, an environment I have consistently seen in every IT group I have ever worked with. Our latest discussion concerned the concept of FIFO work on projects ...

... when presented with five things to do, I will only [emphasis added] work on them in the order received.

This is an exceedingly poor assumption for your personal run-rules, and a short-sighted objective for a PMO that needs to be aligned with the business.

You can't assume or aspire that your PMO can be a finite scheduler for IT. There is too much variability, softness, lack of clarity, process, etc. on most projects – especially at the Application Layer. Once you get anywhere close to business process and the fluid nature of business requirements, you have to have a strong element of agile, flexible resource scheduling and response.

<aside> One might say that the lower you go in the seven-layer stack, you have a better chance of finite scheduling this stuff – projects can and should be more highly predictable, highly engineered. </aside>

Another bit of the conversation uncovered an interesting insight; is there "too much" communication overhead? The effort involved to document something completely, to build a detailed work plan, to create a detailed, multi-line resource forecast – yes, these all represent large chunks of work that do little to make something happen on the screen / in the database. However, the value of such effort is quite high, because the results facilitate complicated conversations in the future. It’s just like the idea of capturing requirements early on – saves tons of rework later.

<aside> That last analogy begs a contrast to agile development - but agile values and requires focused communication and rapid iterations, which can be tough in an environment of thin resources and a high volume of "open" projects. Some elements of the classic waterfall are helpful when keeping multiple plates spinning. </aside>

A final quote - actually heard someone summarize the situation as "we just have a lot of slow projects". There are two important problems contained in that sentence - "a lot", and "slow". You have more control over quantity and duration than you may think ...

Previously ...

• End-around the Prioritization Process (August 14, 2004)
• Communicating Complex Technical Concepts (March 21, 2005)
• If you want to be more than a programmer, stop programming (April 8, 2005)
• Subdivide a huge project list to simplify the prioritization process (October 27, 2005)
• Documentation Redux - a Shorthand Proposal Framework, and the PMO Surprise (July 30, 2006)
• Driving to a Decision on your Projects (February 10, 2007)
• Thoughts on Why Tech Folks Need to Sweat the Administrivia Details (July 14, 2007)
• PMO Prioritization - Project Descriptions should be Effective, Relevant ... and Short! (December 9, 2007)
• How to Cheat at the PMO Prioritization Game (December 14, 2007)
• How to Win at the PMO Prioritization Game (December 18, 2007)
• Tactics for Controlling Project Scope (January 5, 2008)
• Do you want it good or fast? Prioritizing Time-to-Value over Requirements (February 10, 2008)
• Rules of Golf - Project Prioritization Process Needs Clear Documentation (February 18, 2008)

Technorati Tags: business value of IT, documentation, PMO, project management, tech management

Invisible Technorati Tags:
cazh1,
James P. MacLennan,
jpmacl,
MacLennan,