When I joined Thought Ensemble, one of the first things I was asked to do was participate in a Myers-Briggs Personality Assessment. Not surprisingly, I was determined to be an ENTJ – Extroverted, Intuitive, Thinking and Judging are the attributes that I tend towards. I can’t say I was too surprised at the results. I am, in general, a very vocal person. I think in real-time and will often reach out to others with no other purpose than to verbally think in real-time with someone else.  

Living in IT means living in a world where details are often not known until a project advances to a higher state of maturity, hence the Intuitive side, the side that is governed by models and frameworks; concepts and ideas is where I tend to live. This is the skill project managers use every day when we are asked to derive the work breakdown structure (WBS) of an initiative and surmise as to what needs to be done to move the business objective from Point A to Point B.

Despite that lack of structure, the Thinking side of me very much seeks structure. This is my need to know and find the answers side.  It’s the OK, I now have the WBS framework… now I need the full project schedule complete with resources, dates, durations, etc. fully loaded and ready to present to my sponsor side. This means I like to know where I am supposed to go so that I can rally the team to get there.

Finally, the Judging side says that I tend to favor a methodical approach to projects typified by aligning teams on a schedule, starting as early as possible and proceeding in a systematic, ideally predictable, way. Everything you would expect to find in a project manager, right?

Well, there was one wrinkle. On the spectrum of Planful versus Open-Ended, I affiliate more with open-ended tendencies. Ok. So, perhaps not something you would expect in a project manager, but let me explain. How many times have you walked into the room as a PM and been handed a date that the business had already agreed to. Furthermore, no one in the room can rationalize the plan as to what needs to be done to hit the date, what resources are required and who is even available to help you hit your now arbitrarily manufactured date? If you are a seasoned PM, the answer will be something like “More times than I can count!”

Yes, indeed we are 19 years out from when the Standish Group scathingly reported about IT project failures and almost nothing has changed. Standish, in 1995 published the following:

FAILURE RECORD

In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects. The average cost of a development project for a large company is $2,322,000; for a medium company, it is $1,331,000; and for a small company, it is $434,000. A great many of these projects will fail. Software development projects are in chaos, and we can no longer imitate the three monkeys — hear no failures, see no failures, speak no failures. SOURCE:  http://www.csus.edu/indiv/v/velianitis/161/ChaosReport.pdf

Ten years prior to this report the then President of a company called Transarc, Alfred Spector, wrote a paper comparing bridge building to software development. His premise was that bridges are normally built on-time, on-budget and do not fall down. Software, however, seemingly is always late, always over budget and nearly always breaks down.  

In 1986, at the publishing of this paper, software development was in its infancy. It could be argued at this time that the IT industry simply lacked the same knowledge that the construction industry had about how to build bridges, so that they don’t fall down.  Construction crews at that time could pull on roughly 3,000 years of experience. Software engineering had the benefit of a fraction of those years. So, quite reasonably, it could be argued that software development projects were late and over budget simply because it was an imperfect science.

I would add a further argument to this:  you can’t approach software development the same way you approach other kinds of projects: building a house, a car, an airplane, etc.  What we have learned in 19 years is that we need a different paradigm. One alternative paradigm is Agile Software Development and Agile Project Management. In my experience, this is one of the most promising approaches to ensuring high customer satisfaction.  Waterfall simply does not work and has advanced no further than the Standish group’s observations.  It’s not that projects fail… projects shift. The business environment changes. The sponsors change. The requirements change.  The definition of value changes. A project is more akin to the physics of motion than they are to the predictability of construction.

As a project manager, I will simply be more successful in delivery if I approach a project, not with the date in mind, but with project value at the forefront.  This is the tenet of Agile. Deliver what the business needs as quickly as possible in the increments they need it in. Waterfall would have staved off delivery until every single feature and function was ready. Agile asks the business to determine which features have the highest priority and says let’s deliver that in a 4-6 week time-frame. Agile is not perfect, and sometimes the dates are truly fixed and must be met, but dates can also be arbitrary constructs and in those instances it is best to talk the business down from the ledge and show them how to avoid over-budget projects delivered late and with questionable value.

Best,

Jonathan P. Goldstein, PMP
McKinney, TX