I had the opportunity while on vacation in Southern Utah recently, to talk with a veteran project manager in the high-tech field. My friend has managed projects for two of the most recognizable names in tech for more than ten years. From my construction experience, I (thought) I saw an opportunity to pitch our time-tested critical path method analysis method for high tech projects, and to demonstrate its value to a young, smart person with responsibilities similar to a construction PM’s. Instead of coming off as the knowledgeable old guy, I received an interesting lesson in Agile Project Management instead.
“We haven’t ever found conventional CPM scheduling methods applicable to what we do”, she told me. “There are too many unknowns in our programming projects. We often end up with a completely different end result than we started with, as a result of the customer really not being able to articulate what they really want or need at the beginning of the project. They often find out they don’t need all the stuff they asked us for when the project started. Or, once we deliver what they’ve asked for, it’s likely to open up a whole new idea, that they want us to keep developing.”
This was sounding more and more like some of our consulting projects, and had my full attention. “How do you estimate your projects?” I asked.
“We’ve found it’s really difficult to estimate the overall project, and prefer instead to break down the job into individual components instead, more bite-size pieces that we can get our arms around, and be more accurate with. Every day, usually at 10am, we’ll have a meeting with all the software engineers and they’ll each stand up, one at a time, and announce what they’re working on that day, and its status. The good thing is that all these people are absolutely brilliant, really smart people who know what they’re doing. So we don’t have that problem to worry about, we just need to try to get them all together at the same time every day. That’s harder than you might think, with these young, smart engineers. They are often up until 3am programming on any given night, so getting them in at 10am can be harder than it sounds.”
By this time I was wishing I had been recording the conversation, I was learning so much about a completely different, yet similar discipline. “What do you find is the “real” factor, to apply to their estimates when you can get them?”
“I like to think that double is reasonable, but often it takes 3 times as long as they say it will. We’ve gotten used to it, and try to communicate often with the customer, but sometimes it’s still really challenging to set realistic expectations.”
“So you must need some kind of schedule”, I persisted. “For our consulting projects, we like ConceptDraw’s MindMap, which gives us a visual structure, with rough dates sometimes Our industry is very visual, so we find that usually helps,” I offered.
“Sometimes we do that too. Often I’ll use a simple bar chart in Excel, which is about as detailed as we find it’s reasonable to get.” She went on to elaborate that within the Agile Project Management methodology, there are different schools of thought. SCRUM is one of the many that is popular in high tech, and the one that Twitter uses mostly. There are annual SCRUM conferences in different cities around the country, too.”
One more question I couldn’t help asking: “So how many people at Twitter use PC’s?”
Without hesitation, I got the answer I was dreading. “Hardly any that I can think of, none really.”
In conclusion, it’s obvious that high-tech project management methods are too loose to efficiently run the very process-oriented, well-defined results of a construction project. But for some fast-track pieces of a project, and for some of our consulting work, I think that there are some valuable lessons to take away from Agile PM. And I have to ponder that sooner or later, will I too be a Mac user? Nah, that won’t ever happen. But I do like this ChromeBook that I’m typing this on.
