Early in my PM career, back in the 1980s, I was assigned the technical leadership of a software migration effort. I dutifully identified tasks, resources, and loaded those into the MS-DOS version of Microsoft Project (remember the days?) I then proceeded to assign the tasks and track their progress. Before that, though, I noticed that some of the team members were assigned more than full-time responsibilities, even though they were supposed to only work part-time in the project. So, knowledgeable person I thought myself to be, I applied resource leveling to the project. It became a mess and ended not having any reflection to reality!
That project, my first one, taught me that there’s more to managing a project than putting together a Gantt chart (or PERT/CPM if you rather do it that way). In particular, when it comes to software, it is next to impossible for the PM to know exactly what will happen when and how long it’ll take. As it is, in many cases even the people doing the work, the “experts” who provided the initial estimate, do not know it until they “open the box” and peak in.
Fast forward to 1993 and I am in charge of developing Intel’s first client/server system (what can I say, I’m a dinosaur!) to support the Intel Inside ® Program. How do I manage this unknown monster? No specification had been written. The Program was managed by a third party who wasn’t too happy to hear we were building a system to replace theirs. Plus we (the development team) could not even look at it to avoid IP issues. The standard methodology at the time was still a waterfall methodology that presupposed extensive requirements and design activities. It was not even clear what the customer (also my boss) wanted but she wanted it “in three months!”
I took some gambles. As a recent speaker at North Carolina PMI chapter called it, the other side of risk is opportunity; this was definitely one of those situations.
First, since I had been identifying and on boarding client/server technology, plus the only other alternative was the mainframe (IBM 3090 running CICS, etc.: ugh!) I decided it was time to eat my own words and do it in client/server (yes, it was my decision). Second, I identified a consulting firm we had been working with to be the lead development team. Third, I had two other teams to manage, one in CA and one in England, so we divided the effort based on business areas.
The consulting firm went off, prototyped an initial set of capabilities, got feedback from the users and presented us with the first version a few months later. It then asked “what next?” I quickly realized that this was a different model and stumbled into what was then known as iterative development and now would be closer to Agile. We figured that we had to give the teams more work, so we decided on various releases and their contents, had a modeler work on the requirements, etc. Sounds cleaner than it was but it would take too long to describe it here. While I could never answer when it would be done, we kept providing value to the users so no one ever asked me! I then realized that providing something of value, as quickly as possible, to the users bought so much goodwill that the typical how much will it cost and how long will it take discussions never came up!
Fast forward again to 2007 and I’m in charge of leading a program to develop the IT capabilities to support a SaaS capability being launched by my company “in June 2007”. The overall program had been delayed due to funding issues within IT but we had received funds to “scope” the program. We used them to develop the requirements and functional designs until we got the green light. At that point, I used the map day concept described in other blogs to get the team organized. By the second map day we knew we could not meet the June date but could do it by October. The customer asked us to split the deliverables so that we would be closer. We agreed on August and November and met those two days. In the meantime the customer slipped, so we were ready for them!
In the meantime, more traditional approaches to PM in the various organizations I’ve been in continued to struggle. The commitment-based project management, of which map days is one of the features, delivers consistently and predictably when properly applied. I am in the process of teaching it to other PMs in my organization and working on rolling out public courses as well as a tool to manage the process. Send me a note at [email protected] if you are interested in attending a course or are interested in the tool. In the meantime, read No Surprises Project Management by Timm Esque.
Jose Solera, MBA, PMP
