The pace of adoption of innovation in project managementIt is the end of October now, and as Halloween approaches, we drive by graveyards, open tombs, and skeletons, some of them funny, some not so much. In some cultures, like in Mexico, “Dia de los Muertos” is the day to honour the dead. In North America we dress up our kids in costumes and walk the streets for candy, Mexicans take food and tequila to the cemeteries and party all night. Hey, we Latinos can make a party out of anything!
Skeletons are innocuous when they remain in their coffins. The problem is when they pretend to be alive and, even worst, when we listen to them, as if it were still their time, when it is not.
Project Management has been accused of being a thing of the past, a dinosaur, a cadaver that enjoys surprising health. In 2002 a group of developers got together at a ski resort in Utah and came up with the Agile Manifesto, which was an elegant way to tell project managers to get out of the way and let developers do what they do best: build software without the interference of project management and project life cycle processes and rules.
While this is not a call to go wild and back to “cowboy development”, it should be interpreted as a wake-up call. Software developers, computer engineers, etc; are usually the bright kids out of high school, the nerds with a cap and propeller. However, the question is: what do you call a nerd twenty years after graduating from high school? The answer is “boss”.
Project teams get these bright kids who, after college or university and years of experience, are even smarter. And what we do is treat them like complete idiots. We, project managers, need to tell them exactly what to do, otherwise they will not be able to figure it out on their own. After ten years of agile practices and even PMI jumping on the bandwagon to cash in with a certification (PMI: agile was never about project management to start with), it is now widely accepted that business analysts, developers, testers, are not idiots after all. All we need to do is tell them what the goal is, and when it needs to get done, and they will find the best way to do it. Like in my favourite line in Jurassic Park: “nature will find its way”.
However, many project managers, and even methodologies, still cling to the past. And this is not about agile VS waterfall; it is about management VS leadership, it is about telling people what to do VS facilitating the conditions for the team to excel; it is about taking the driver seat or the back seat, and let the team drive.
Going back to the theme of this article, it is interesting to draw a parallel with the industrial revolution, which was triggered by the great invention of the eighteen century, the Steam Engine by James Watt, a Scottish instrument maker who created an innovation that changed the world. For centuries, industrial facilities had depended on the flow of water from a river to draw power using a wheel connected to a number of axles through a complicated arrangement of pulleys and gears that were in movement all the time. Each workstation only had to hang a leather belt from the overhead axle and they were connected to the source of power. This model had many problems: first, it was all or nothing for the whole plant; second, and most important, it depended on the flow of water: no water, no power, and in North America and Europe, water during winter time tends to freeze, so mills had to stop until the spring, when the problem was to control the excess flow from the meltdown. With Watt’s invention, none of these problems existed. All they had to do was store sufficient water, and here is where the “mill pond” comes from, so water could be drawn and boiled into steam. Although not perfect, it was a better solution. Not the best job for those shoveling coal day in day out, and fires were frequent, but it worked. So mills all over the world installed steam engines, which powered the same mechanism of axels and pulleys they had before, and the industrial revolution came to be, kids were exploited, Dickens wrote his books, fortunes were made, and people got used to cheap goods they could take home. Life was “good”.
In the nineteenth century, another Brit, Michael Faraday, an Englishman this time, invented the electric motor. It was cleaner, safer, and more dependable than the steam engine. So factories all over the world quickly adopted the new technology, replacing the obsolete steam engine with a huge electric motor. Nothing changed, it was just cleaner and safer, but the way of doing things was still the same.
It took seventy years, or three generations, for industry to realize that the advantage of the innovation they had adopted was the ability to install small electric motors at each work station, so they could be turned on and off at will, and speed controlled to suit the task at hand. Seventy years to realize the potential of technology, of the innovation they had already adopted. Do you think it is silly? Keep reading.
The history of project management is surprisingly similar. As a discipline, project management emerged after the Second World War in the aerospace and defence and engineering and construction sectors. During the fifties, sixties and seventies, mainframes became affordable for both the private and public sector. Project management software came to be in early versions of products like Open Plan, Artemis and Primavera, which are still around in some form. There were no PC’s at the time, no networks, no tablets or cell phones; only a mainframe in a protected environment, with raised floor and a group of chosen ones who could tame the beast, taking punched cards in and coming out with white and green reports. That is the world I got to know when I started my career as a project manager in the oil industry and then in the engineering consulting sector, in the late eighties.
Because of the central concept dictated by the mainframe, the model worked as follows:
- A command and control approach to program and project management, with project managers cracking the whip every five minutes or so, pushing teams of hundreds of engineers and draftsmen creating blueprints and other documents. It was the industrial revolution all over again, just cleaner.
- Engineering projects, as predictable as they are, can be defined in advance in an excruciating level of detail, so the mainframe was fed with schedules that had thousands of tasks. Updates were fed to the mainframe and we got back reports with the state of the project. Considering how primitive the technology was, we did pretty sophisticated project management. Today I have to smile when students and project managers tell me that Earned Value is complicated. We did it back then with punched cards, pencil and paper. We had no PC’s, no Excel, just paper and pencil, and a brain.
- While this was happening in the aerospace and defence and engineering consulting, IT was just getting started with project management. As software companies and IT departments in banks and insurance companies (some were called IBM Department, believe it or not), the need for project management became obvious. As projects got bigger, more complex and difficult to manage, IT turned to the “pros”, the hard core engineering PM’s, to help with project management. Engineering Consulting firms saw the business opportunity and spun off firms to sell this know-how to industry. I happen to work in one of those firms, and project management was our product to sell.
- In the eighties and nineties, many PMs decided to jump ship and got hired by IT departments and software companies. I was one of them, and we did what we knew best: we replicated the model that worked so well in engineering consulting, and it failed miserably. First of all, engineers are easy to manage: us engineers tend to be structured, predictable, we follow process and rules. A command and control model works well with engineers. On the exact opposite, software engineers, architects, developers, are a different breed: they are artists, they are creative, they are constantly coming up with new things. Some of them can be “prima donnas”. A command and control model doesn’t work well with these people, but we tried anyway, and we failed. In the early nineties, the Standish Group surprised the world with the “Chaos Report”, a research project based on thousands of IT projects all over the world, and it was not pretty: only one out of three projects in IT was completed within a reasonable time and cost variance and meeting scope. The vast majority of IT projects were outright failures, with average overruns of 200% and up, severely behind schedule and over budget.
- Continuing down memory lane, in the eighties and early nineties we got a number of innovations that had great potential to improve project management in IT: the PC, the network and, you guessed it, Microsoft Project.
- So what did we do with these new capabilities? We made exactly the same mistake that was made in the eighteen century with the electric motor: we replaced the mainframe with a PC on steroids, or so it seemed at the time, installed MS Project, and ran the show exactly the same way as before, only cheaper. We put schedules with thousands of lines through MS Project, and it choked and crashed (twenty years have passed and still does…). We printed the schedules, some even printed PERT diagrams and used them as fancy wall paper to impress the bosses with the sophistication of the project management profession. These schedules and PERT diagrams stayed on the walls for months and years, and who would even think about updating them; that would be too much work. We were material not for a Dilbert strip, but for a complete book.
- As we geared towards Y2K (for the younger generation, we thought that computers would stop working when clocks would go from 99 to 00, Terminator would come and destroy the world as we know it; at the end, nothing happened, but there was plenty of work for all of us for a few years). Shops were busy again, the dot com era was booming and IT was the place to be. The problem, and there is always a problem, is that projects were less predictable every day, as we moved from mainframe to client-server to web, things were just impossible to predict in advance. This is when and why agile emerges, and it teaches project management a lesson or two.
For those who have braved the history lesson and made it to this point, the good news is that IT is finally starting to get its act together. Today the reports from the Standish Group show improvement, while there is still a lot to be done, results are not as bad as before. It took us twenty years, at least not seventy years like two centuries ago, to realize the potential of having a scheduling tool available throughout the organization, and information flowing across projects, programs and portfolios. PPM tools now provide the functionality to support smaller teams, even agile teams, each one accountable for a deliverable or work package, with its own schedule and, most important, self-managed, with a project manager that is no longer a dictator but a facilitator. This is not exclusive to agile, and it is applicable to even pure waterfall projects.
The key idea is to relinquish the need to have centralized command and control, and delegate to teams, empower the leaders and their teams, give them a date they have to make, explain to them how their piece fits in the overall project or program, and why the date is important, and they will deliver.
Remember: you have the brightest kids in your teams. Don’t treat them as idiots. If you can’t handle the change, you are still on time to pick up a skeleton costume for Halloween or, even better, “Dia de Muertos” in Mexico. And don’t forget the tequila: you are going to need it.
