I recently went through the exercise of bringing on a contractor for a six month period to assist with an overload of analysis on various Project efforts. I am continuously surprised at how many different interpretations of “Agile” I get, and how often practitioners within the Project Management arena seem to feel that their value to the discipline is their ability to use tools. Although I agree that the ability and capacity to use tools is important, I don’t see that in the top three skills required to be a good/great Project Manager. I asked each candidate what the bare minimum of documentation is required to move into the Development phase of the Project was, and I was stunned at some of the answers I got. One candidate rattled off so many documents that I felt that he must have thought that his job was measured by the amount of trees he killed!
Today I got a call from a colleague asking about “something that will help me track what members of my team are doing, but I don’t want to track each task, and I don’t want anything as complicated as MS Project”. After a few more questions to really dig into his requirements, I realized that he was really looking for a critical path tool for a number of financial deliverables that were being created by individuals in his team. Each member worked on one of these deliverables at a time, and there was no crossover – when they individually completed their analysis and delivered the spreadsheet and recommendations, they moved onto the next one. There were a fair amount of these in his pipeline and he had a team of about six analysts. So, why need a software tool? What would be wrong with a pencil and paper? Or a whiteboard? Why does it have to be so complicated? Why can’t we get back to basics?
I don’t know how long you have been in the profession, but I was around in the very beginning, when the beginning of Project Management was all about the Waterfall way. One step signed off before moving into the next phase. Heavy documentation and thousands of signatures. Slavery to a Project Plan that was thousands of lines long, and the minute you tried to level the resources, the whole plan exploded! I remember even then thinking “why does this thing spit out one eight hour window as an end date that there is no hope of meeting this early in the game?” Is it really all about the tools, or is it really about our brains? Isn’t that our value to the organization?
Now there are definitely Projects where being too simple won’t work, I realize that. Projects that last years with many different vendors that need to be coordinated through the critical path would be a great example of this – obviously a pencil and paper or whiteboard wouldn’t be the BEST way. However, I think we sometimes get stuck utilizing the same tools and try to fit everything into the same process without considering that there might be a more flexible/easier way to accomplish the same thing. I know sometimes I sound like a broken record to my team, but one size does not fit all.
So, if you work on different types of Projects like I do, what can you do differently in the future that will be easier and more flexible, but still reach your goal of a completed Project that the sponsor agrees meets their need? I don’t know about you, but with the number of Projects that exist in my Project Pipeline, I don’t have any time to waste, and I’m willing to use nothing more than an email deliverables list as a Project plan if that’ll do the trick! Think "Barely Sufficient", with the speed and volume of our Projects, it's a method of survival!
Margaret de Haan
MBA, PMP, CSM