Perfect IT

I once met with a rather thoughtful Project Manager to catch up on things. An interesting person to talk to – it’s the cadence and style of his chat, he’s a fairly laid-back guy. I asked where his Stress comes from – he shows no visible signs of any, and it made me Ponder. We ended up talking about golf, IT Projects, and the “Search for Perfection” in our work.

So, what is “perfection” in the IT world? Is it being able to predict what will come true, and then everything hits as you foretold? Or does it appear when the programming / configuration / cabling is done, and everything does exactly what it was supposed to do?

Consider time-boxed (or agile) projects versus the traditional waterfall style. Is “perfect” acheived by hitting the date (but not getting all the requirements), or should we value delivery of all of the requirements (but not in the originally estimated time)?

Back in the day, we would work to write code that compiled “perfectly” – no severity level 20’s or 10’s, as we used to say in RPG.

What about fault tolerance, scalability, or quality of testing? These “requirements” deliver business value when [bad] things fail to happen (some tao to jones on). Note that these …

I once met with a rather thoughtful Project Manager to catch up on things. An interesting person to talk to – it’s the cadence and style of his chat, he’s a fairly laid-back guy. I asked where his Stress comes from – he shows no visible signs of any, and it made me Ponder. We ended up talking about golf, IT Projects, and the “Search for Perfection” in our work.

So, what is “perfection” in the IT world? Is it being able to predict what will come true, and then everything hits as you foretold? Or does it appear when the programming / configuration / cabling is done, and everything does exactly what it was supposed to do?

Consider time-boxed (or agile) projects versus the traditional waterfall style. Is “perfect” acheived by hitting the date (but not getting all the requirements), or should we value delivery of all of the requirements (but not in the originally estimated time)?

Back in the day, we would work to write code that compiled “perfectly” – no severity level 20’s or 10’s, as we used to say in RPG.

What about fault tolerance, scalability, or quality of testing? These “requirements” deliver business value when [bad] things fail to happen (some tao to jones on). Note that these also become bargaining chips when time is tight … ephemera less valuable than squeezing in one last combo box.

Obviously there’s no right answer, but my calm PM friend and I feel that one’s definition of “perfect” says a lot about whether or not you experience stress at work; this is when the conversation switched to golf.

Why do we both like Pasture Pool? Neither of us are competitive by nature; it’s more of a way to search for perfection (or burn an afternoon, or get some bidness done). And the interesting part is, it could be this never-ending search …

Where do you go when you can par your favorite course – for a lower score, or the next course to the left?

According to the zen PM, “if I’m a 15 handicapper, I could get down to 20 handicapper with more practice” [ok, he clearly plays more than I do], which led me to ask what exactly is a “perfect score” – is it par golf? zenPM suggested that a perfect score would be birdie every hole; I thought perfection could be when you hit every fairway and green in regulation, and you’re down in two.

So is perfection “peak performance” [on time], “consistency and predictability” [on budget], or “strictly following the rules” [no 10’s]?

Then we had to get to our next meeting … back to the stress …

Previously …

• How to Cheat at the PMO Prioritization Game (December 14, 2007)
• Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
• Rules of Golf – Project Prioritization Process Needs Clear Documentation (February 18, 2008)
• Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
• Agile Methods in a Waterfall World: Speaking In Code (September 29, 2008)
• News for Wombats: Taming Unreasonable Requirements (January 26, 2009)
• Failing Faster (June 14, 2009)

Technorati Tags: business value of IT, collaboration, people management, project management, tech management

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