Saturday , February 25 2017
ITMPI FLAT 002
Main Menu
Home / Authors / Blogging Alliance / Why #NoEstimates Is a Rough Finish for Your IT Career

Why #NoEstimates Is a Rough Finish for Your IT Career

BloggingAllianceButton
I live in the American Southwest—the Mojave Desert, to be specific. We have massive areas of land covered with nearly identical homes, built in clusters called “developments.” The term is meaningful, because the builders aren’t just building houses; they are developing entire communities.

Complexity Lives at the Business Level

We have a well-established process: The organization with the right to build on a tract of land proposes a plan, which is reviewed by a planning commission. Approval usually comes with stipulations and concessions, from widening roads and funding storm drainage to possibly even contributing land for an elementary school. The developers then arrange for the site to be prepared, laying in utilities and streets, traffic signage and environmental controls. Then a specialty firm lays out and pours foundation pads for the planned houses, and at some point, carpenters come in to frame the houses. Other specialists put in the electrical and plumbing, tile the roofs and hang the windows and doors, stucco the exterior walls, drywall the interior, and install cabinets and countertops. These activities aren’t performed house-by-house, but a street at a time.

Estimates Are Table Stakes

Now, picture a carpenter who has been asked to bid on framing a group of houses. He replies that he can’t tell how long it will take, because his crew hasn’t built that model before. But if the home builder gives them, say, $400,000, they will work diligently, and when the money runs out, they can decide together whether to put more money into the construction. You’re probably thinking that the builder won’t ever do business with that carpenter, and neither will anyone else in town. But that’s because the carpenter isn’t an employee—he has competition. This helps explain why certain software developers think #NoEstimates is a fine idea—they don’t perceive that they have competition.

Coders often claim that they are bad at estimating, and so it is counterproductive to ask for them. Never mind that coding is only one piece of the effort to deliver a product. Never mind that the market waxes and wanes. Never mind that the organization has other potential uses for their capital. Never mind that other specialists will be called on at certain times to contribute their knowledge and skills, and they need to make their own work schedules. Never mind that marketing needs to begin well before there is a shippable product. None of that matters, because coders are only good at coding, and estimating is an unproductive distraction.

Your Future Probably Doesn’t Include Employment

There has been a remarkable shift over the last generation: There are fewer employees and more contingent workers in virtually every business, in virtually every market. Entire business functions have been outsourced. Few companies administer their own employee benefits or payroll. IT services are being taken over by global firms that simply “re-badge” the workers they want to retain. Apple manufactures nothing; they simply contract with hundreds of suppliers to have their designs turned into hardware. Software-as-a-service is replacing bespoke and even packaged software applications developed and maintained by internal resources.

As a contract project manager, I am an efficient competitor, negotiating favorable agreements with global firms that want to reduce their risks. They like doing business with me, because I speak the language of business, not project management. I give them a statement of work, with estimates, assumptions, stipulated roles and responsibilities, milestones, a specific change control process, and professional references. We understand each other, and they are willing to pay a premium for that level of understanding.

If you are a software developer or manager, contingent work is in your near future. Software development isn’t about coding; it’s a business function, like residential carpentry. You need to ask yourself: Who is my competition? And why would I lose to them? Then take some time away from learning the newest cool development tool to become viable as a contingent worker. Otherwise, you might end up standing in the parking lot at Home Depot, asking departing customers if they need some help for the day.

 

For more brilliant insights, check out Dave’s blog: The Practicing IT Project Manager

View the press release for his new book too: The Data Conversion Cycle

About Dave Gordon

Profile photo of Dave Gordon
Dave Gordon is a project manager with over twenty years of experience in implementing human capital management and payroll systems, including premises-based ERP solutions, like PeopleSoft and ADP Enterprise, and SaaS solutions, like Workday. He has an MS in IT with a concentration in project management, and a BS in Business. He also holds the project management professional (PMP) designation, as well as professional designations in human resources (GPHR and SPHR) and in benefits administration (CEBS). In addition to his articles and blog posts, he curates a weekly roundup of articles on project management, and he has authored or contributed to several books on project management. You can view his blog at The Practicing IT Project Manager by clicking the button below.

Check Also

What’s Wrong with the Productivity Race?

Everyone is happy getting off work with the productive feeling of having everything completed. However, ...

3 comments

  1. Coders and many agile enthusiasts often overlook Dave’s statement:

    “Never mind that coding is only one piece of the effort to deliver a product.”

    Which is why agile and its associate concepts, like “no estimates”, only comes into play after an overall project is set up, general requirements established, architecture is defined, possibly some general design work is done, a general schedule and costs are defined and agreed to, the team is hired and trained, etc. All those things take time and require that the recipient/client agrees to some notion of “how long”, “how much”, and “what will I get”. A plan calling for “slinging code until it’s done” should not be acceptable.

    • Well said, Gene. I asked a well-known Agile thought leader: “Who is responsible for organizational change management under Scrum?” The reply was, “The ScrumMaster.” My response:

      A Boy Scout Troop boards a plane for Denver. In mid-flight, the pilot has a heart attack. Who lands the plane? Answer: the co-pilot.

      A project plan has to include both internal and external dependencies, and participation by knowledge specialties that are not part of the core team. The #NoEstimates arguments proceed from a “Gilligan’s Island” world view – there are only the seven of us, and anyone else is at least an outsider and most likely a threat.

      Thanks for taking the time to comment!

  2. I think there is a fundamental misunderstanding of the #noestimates position. Using the framing a house example, would you ask a builder to estimate the number of nails he will use on each wall? Or would it be a better use of his time to estimate how many nails he will use on each floor instead? Asking a team to develop estimates at too detailed a level wastes time and creates churn.

Leave a Reply

Your email address will not be published. Required fields are marked *

Get the best IT management articles right in your inbox
Subscribe
Join 15K subscribers