I recently blogged about a small software project with which I'm involved that is
saddled with using a waterfall project methodology; I have never been a fan of the waterfall method but, on this project, I am being engaged through another consulting company that is providing the project management, so I have no choice. I've estimated that the software development portion of the project will entail 120 man hours of effort -- a very small project. Yet, for this small 120 hour project, I've seen 3 major revisions of project scope documents and four weeks slip by while the project manager attempted to "nail down the requirements" with the client.
Now it appears the client has signed off on the "final" project scope document and is ready to begin the project. So the project manager met with us on Friday to kick off the project and discuss the project plan.
A 105 step project plan!
For a software project that is estimated for 120 man hours.
To paraphrase Churchill, never in the face of human endeavor has so little been tracked by so many to so few.
At this point, the client has many pages of requirements documents and an exhaustive project plan, but not a single line of working software code. The management structure of the project has already consumed more time and effort than the actual development of the project's ultimate deliverable -- working software.
Somebody please explain to me how anyone can still place any value on this style of project management.
I recently read a very good blog post on More Than a Living in which the author, Rick Turoczy, posits that an artisan is more important than their tools. Seems rather obvious when it's worded like that, eh?
The author makes an excellent point.
People are quite protective of their “tools.”
Oooh. Tools. They’re oh-so-valuable. Lah-di-dah.
Their software. Their methodology. Their ways of doing things. Little flowcharts. Templates. Processes. Scorecards. Whatever.
The perceived value of these tools is huge.
But what about the actual value?
I’d say that there isn’t much value in the tool, at all.
In reality, a tool only becomes valuable by being a tool. By becoming something more in the hands of an artisan to manipulate it.
An artisan can quickly transition to new tools. In the MTL article, the author discusses Toby, an Excel whiz. A spreadsheet is Toby's tool. Excel may be his choice of paintbrush today, but I'm sure he can very quickly pick up any other spreadsheet program and quickly produce a masterpiece. He is master of financial modeling.
Over the years, I've seen technology job postings become extremely tool-specific, e.g. the following required applicant skill set pulled directly from a job listing on dice.com. I've edited the layout of the post for reasons of legibility, brevity, and removal of pure BS.
- Experience in Web-based software application development experience to include:
- internet integration server (iis) / active directory (ad) / SQL Server 2003 & 2005, SSIS, Visual Studio Team system.
- Understanding of intranet / extranet development / reverse proxy/Share Point portal / windows Share Point services.
- Understanding of impacts of multiple locations spread out globally connected by wide area network of varying speeds with varying desktop configurations.
- Understanding of multiple language, currency and locality impacts
- Use and development of web services
- Good software development practices including controlled processes and separation of development, test, and production environments.
Contrast these job requirements with the idea of an artisan being more important that their tools. One cause of this type of job posting is the need of headhunters and HR personnel -- through no fault of their own -- to have a checklist with which to filter candidates without consuming valuable interview time and resources. But even so, this type of job posting seems peculiar to technical industries. Have you ever seen a job posting for a carpenter that required 2 years experience with a Stanley 22 oz Antivibe Framing Hammer? Of course not.
Given an applicant's demonstrated competency in my field (programming in my case), I don't hire based upon experience with specific tools. Instead, I've always tried to hire based upon three criteria.
- Motivation. Does the candidate show a history of completing tasks and projects? If presented with a problem, do they truly attempt to solve it? Are they lifelong learners? Do they read technical books and journals? Do they play with new technologies? Is this a profession or merely a job?
- Intelligence. How do they solve problems? When presented with a problem, do they latch onto the first solution they dream up, or do they develop and evaluate multiple possible solutions? Are they open to new ideas? How well do they think through the balancing of conflicting ideas, requirements, and solutions?
- Personableness. How well will this person fit on the team? I try to imagine the person on the team and how the other team members will relate with them.
Given the potent combination of motivation and intelligence, a Java programmer quickly becomes a C# .NET expert -- or vice-versa; experience with specific tools is nice, but relatively unimportant. But even motivation and intelligence must be balanced with how well the candidate will fit in with a team; even the most talented performer isn't worth the cost of disrupting your team. Terrell Owens is arguably the best receiver in the National Football League, but he has eventually poisoned the locker room of every team for whom he has ever played.
I would never turn down a top-shelf developer because they didn't possess experience in a particular toolset. I don't hire carpenters because of the type of hammer in the tool belt, but rather their knowledge of construction techniques, materials, and craftsmanship. It was Einstein the artisan that revolutionized physics, not his writing implements and certainly not whatever brand of slide rule he used. Mario Andretti not only won auto races in many different types of cars, but also in many different types of auto races.
If you wanted a portrait done in watercolors, would you rule out a Rembrandt because he primarily worked in oils and engravings? I thought not.
Drip, drip, drip, drip.
Let's take a road trip. I want you to drive me to California from South Carolina, but I'm not sure exactly where in California, just somewhere in the southern part of the state. I'll know it's the right spot when we get there. I need you to provide me with an extremely detailed itinerary, specifying the exact time and location of waypoints along the route. And you must provide this itinerary by merely consulting a map, you cannot check weather or traffic conditions. In fact, you're not quite sure when we'll be making the trip, so you can't even take into account the season. Now imagine we'll be using a bus on this trip, and all the passengers will be giving you directions and asking for stops along the way -- but you're not allowed to talk to these passengers before the trip. I still need you to provide a firm timetable and cost estimate for this trip.
This hypothetical trip is an example of a wicked problem - a problem whose requirements and limitations cannot be entirely known before completion.
Drip, drip, drip, drip.
Three weeks ago, my company was presented with a small project that we estimated would take about a man-month to perform. Since that time, we have met with the Business Analyst (BA) on the project three more times, and each time, the requirements have changed and we've been asked to re-estimate the project. Moreover, with each estimate, we're asked to provide more detail and clarification. We have had no direct contact with the ultimate users of the proposed system. During this time, the BA has produced a few versions of a very nice requirements document, but right now, the customer has no working software. Instead, the project is going through an endless loop of analysis paralysis.
If the project had kicked off three weeks ago, it would likely be complete by now. The customer could be using the software and providing feedback to the development team so that the software could be further refined to solve the users' particular and unique needs.
Drip, drip, drip, drip.
This situation is the inevitable result of the use of the waterfall project management methodology. The benefits of working software are being sacrificed for the illusion of control. I view this as shooting a bullet at the moon; if your assumptions, calculations, and aim are absolutely perfect -- and no unforeseen circumstances occur -- it just might work. But wouldn't it be better to embrace change? To build flexibility into your methodology to accommodate change, mistakes, and unforeseen circumstances? Wouldn't it be better to pilot a projectile to the moon?
To go back to our California trip analogy, instead of creating an extremely detailed itinerary, why not create a general overall goal and timetable with smaller chunks of milestones. For instance, let's just say our target for the first day is to reach Jackson, Mississippi and spend the night there; we'll cover a good amount of ground, but we'll allow for a bit of time to deal with traffic in Atlanta and maybe a bit of weather near Birmingham, Alabama. We anticipate arriving in Jackson in time for dinner, but if we decide as a group to take a detour to see Stone Mountain outside of Atlanta, we won't stress about arriving a bit later in Jackson. Conversely, we may breeze through Atlanta and arrive in Jackson in early afternoon. If so, we may decide to keep going and perhaps stay overnight in Vicksburg, overlooking the Mississippi River.
But we will have a goal of getting to California. We will have a general strategy (itinerary) developed from maps and previous experience. And we will have a set of tactics to deal with unforeseen circumstances. Some of those tactics may be mitigating the risk and impact of unforeseen challenges by carrying extra maps or a GPS, cell phones for communication, credit cards for ready access to cash, and most importantly an adventurous attitude willing to embrace change.
The point being that we will drive "within our headlights". We will set short, reasonable goals that we can accurately predict and work to achieve those goals daily. If any of those goals are not met for some reason, they are reassessed and tomorrow's goals may be adjusted -- perhaps we won't be able to go see the world's biggest ball of string tomorrow. Who knows, with a more relaxed atmosphere on the bus, everyone might even enjoy the trip.
Instead I'm reviewing yet another change in the requirements documentation. Three weeks of "planning" and "nailing down requirements" for a 4 week project.
Drip, drip, drip, drip.