PeterSchuh.com

Estimates are a fact of life for most of us. And often – while not always – they are a necessity. If I weren’t using some form of estimation on my current projects, they would be twisted up like Sherman bow ties. And on fire.

This brings us to an apparent paradox. The larger and more novel something is, the more we need to put some estimates around it – lest it end up a railroad-side barbecue. Yet the larger and more novel something is, the tougher it is to devise meaningful estimates.

But this isn’t a real paradox. It’s just a starting point.

At the very inception of a project or product we don’t need a thorough estimate of everything. We just need a simple set of estimates that tell us what to label the tick marks on our deliverable-level cost graph. Were we to cost out our initial estimates, would we be measuring project deliverable in increments of one thousand dollars, or ten thousand, or a hundred thousand? This lets the organization and team know what league they are playing in and how much to invest in upfront estimation and project tracking.

Most things we need to do should not be difficult to estimate. Anyone who’s been around the organization long enough should know how long it takes to spin up a shared development environment, the average time to build out a screen, and the usual duration of system and acceptance testing. For the rest we use development spikes.

We use a development spike to tell us whether some technical activity is feasible and/or to tell us how long it could take to complete.

Here are some examples of development activities (and questions) that learn more about with a development spike:

• Can we implement two-way SMS in our current infrastructure?
• Can we reduce costs and time by using an open source charting package (or is it better to roll our own)?
• How difficult will it be to upgrade to Ruby on Rails 3?
• Can we do multiple file uploads without flash?
• Will it handle the load?
• How do we make these two systems talk to one another?

A spike is typically throw-away code. It’s only purpose (at least in this case) Is to give us enough knowledge to state a fuzzy estimate with confidence.

Do you think you are a rockstar project manager? Can you roll out an agile process and leap the tangle of legacy waterfall hurdles without breaking a sweat? Can you walk unaided from a fight club thronged with hackers, cowboy coders, support junkies and alpha heroes? Want to prove it?

I’ve got the acid test for you.

Identify a small product that you have always wanted to build. Commission something that you could use on the job or at home. It needs to be something that requires more than just you to complete. It must require a budget, paid help, realizable value, clear goals, and a plan. In other words, scope and fund your own project.

Yes. You fund the project with your own money. That’s what makes this an acid test.

For me, for example, this something is to rebuild and productize a web-application that has become a critical part of managing the rental properties my wife and I own. We have used two different prototypes over the last two years and I firmly believe this product captures a soon-to-be-ubiquitous element of property management. So I am taking the leap.

This PM acid test assesses whether you have the skill to contemplate and manage everything about your small project (and the product on which it is based). Either directly or via delegation you will need to:

• Define your own requirements and break them into plannable features.
• Identify a MVP (minimal viable product) and keep the project aligned to that vision.
• Find and contract with the professionals who will complete the work.
• Forecast and manage the development schedule.
• Identify the technologies to use and the deployment environment.
• Vet archiitecrure and design decisions.
• Review all completed deliverables from a functional and technical perspectives.
• Balance new features versus technical debt.
• Do anything else a project manager, product manager, product owner, stakeholder or sponsor would do or delegate.

Of course you can get help on any or all of these activities. You can hire an architect to make decisions and review code. You can hire a QA professional to write scripts and run tests. But you still need to acclimate these professionals to your product and vision. And any additional hands will cut into your budget.

Even when delegating you still need to preform an informed review of all significant work products. Delegation without review is an elephant trap.

The only certainty around this acid test is that something will go badly. If you hire four contractors at least one will be a dud – you’ll pay someone to clean up that mess. Your own conception (and delivered specs) of the system will never be free of potholes – someone will need to go back and patch those, or dig up the road and start over. And your vision of the product will never be communicated so clearly as to avoid every misstep – that’s more rework still.

You will need to be on top of everything. Or you can sit back and watch Team Burn Rate blow half your budget in two weeks. Whenever anything goes wrong it will be your fault. You did not give clear requirements. You hired the wrong person. You changed your mind. You let one decision sit too long and made another decision too early. You let a technical issue sit unaddressed as it smoldered its way through your release timeline.

Can you complete a releasable version of your own, personably-funded product before you cut off the money supply because you can’t lose any more? That’s why it is an acid test.

Superflu weekend struck our family — and all the families in our daughters’ playgroup. Based on preliminary reports (and my own condition) this could stretch into superflu fortnight.

This reminds me to ask the question: Has anyone planned for sick days in February?

I spotted a trend a few years back that I blogged about in 2009. Now I’m convinced that February is the Northern Hemisphere’s worst month for sick days. And I do account for February sick days in the delivery commitments that my teams make.

Of course, there are other perspectives. I once had a manager who, when contemplating the likelihood of illness-reduced delivery in February, rebutted: Plan at the standard velocity. That’ll encourage the healthy employees to work overtime and cover the shortfall.

He was all about morale, that one.

I’ve been doing more than my fair share of deployments lately.

These deployments aren’t the one-click-then-beer variety you find on Heroku or in some seriously agile shops. These deployments are arduous day-long journeys, caravanning eight unique technologies, traversing multiple connected systems both up- and down-stream. And bad things do live in the water.

Seriously, it has been a lot of hard work and some difficult times reliving past mistakes. So here’s my list of freshened lessons that make big deployments suck less:

1. One group chat and one conference line. Don’t use email for the deployment team. It’s slow. terrible at threading conversations. And, somehow, people always get dropped off the address list – or appended to the cc field 37 times. A dozen individual chats and phone calls are terrible for anything but proving why Europe mothballed the semaphore back in the 19th century.

2. A deploy with fewer people is better. An all-hands-on-deck deploy may sound comforting. In reality. that’s just more people in the way, arguing over the best corrective path, and slowly burning out while standing at the ready. Deploys with fewer people – with clear responsibilities and fully prepared for the tasks of the day – beat mob deploys any day of the week.

3. Have your support people at the ready. Just because your core deploy team is fully briefed and prepared doesn’t mean you have all the expertise you’ll ever need. Know who else you’ll need if the fit hits the shan. Make sure that each member of this auxiliary group is ready to drop in at a phone call’s notice. Collect and distribute the best contact information for that auxiliary group to each member of your core group prior to deploy day.

4. Clear communication channel. Who owns outward communication and in what direction? People who need deploy status updates could include stakeholders, upper management, cooperate support teams, and auxiliary team members. They will not all want or need the same status reports. (Hint: you don’t want to send a 100-line deploy plan every hour to your stakeholders.) You need to decide in advance who owns which channel, the frequency of status updates, and the content of those updates.

5. Clear decision-making. When your app server and the database stop talking the last thing you need is a team that descends into bickering over which server to kick first. A deploy will involve a variety of experts, but there should be a single person in charge who – once all voices have been heard – calls the shots.

6. Clear accountability. The entire deploy team should know who is responsible for what well before the deploy begins. For me, that means one owner for each discrete part of the deploy. This separation may be by system, technology or product subteam – whatever makes sense for the deploy. Finally, only core deploy team members own deploy tasks. Sometimes a non-team-member is responsible for completing a task, but we still want a core deploy team member accountable to see that it gets done.

We have so many things to fret over when building software:

Requirements. Quality. Deadlines. Budgets. Scope creep.

Dependencies. Audits. Deployment plans. Disaster recovery.

Single points of failure.

Other systems. Other teams. Other everything.

Backouts. Blackouts. Timeouts. Burnout.

On call. Fire call. Five nines. Server down.

Bad managers. Weak programmers. Ill-suited customers.

The random bus.

Perhaps we hold fast to the long-term course. Fortunate, still, our leaders flare near-terms into the night. Even so our endeavor rolls on as involuntary peregrination.

Though it never was how can we return to the way it should be? Create and inspire. Band together for common purpose and tantalizing gain. Strive and fall and lift one-anther higher. Set collective effort on uncommon aspiration. How do we forget to remember? To make something awesome.

I’ve seen it happen several times. The business requests an upfront, full-cost estimate for some feature or functionality. A business person writes something up – far simpler than the normal story-writing or requirements-drafting process. The development team reviews the write-up. Questions, clarifications and adjustments happen. An estimate is assembled and then KA-BLAM! – everyone is blown over by the sheer size of it.

When even the development team is left scratching its head saying: “Yeah, that looks way big to us too, but … ” you know there are problems bigger than whatever comes after that ellipses.

Granted, there are mitigating circumstances. The requirements – such as they are – may delve into a new and unknown domain. The technology may be novel to both the team and the corporate IT ecosystem. But even in these cases, if the team cannot mount a strong justification for an eye-popping estimate, you have to ask whether there are other issues lurking in the shadows.

In these cases, the two most common issues I’ve set alight are:

1. The delivery team lacks confidence in its own technical ability (due to a skills mismatch, lack of training, or other reasons). This issue goes beyond the time it might take to ramp up on new technologies, adjust to a new domain, or proof a novel design approach. Teams can readily explain all this in their estimates. But an intractable problem arises – with a huge estimate in tow – when the development team fears that it’ll never fully tackle a new technology, domain, or approach. Or, sometimes, it’s an unconquered legacy technology, domain, or approach frustrating future development.

2. The delivery teams lacks confidence in its business partner’s ability to honestly collaborate and openly negotiate with the team. It’s okay if the business partner doesn’t get the requirements solidified on the first, the second or third try. Agile teams know this can be difficult, and agile processes are geared to accommodate. However, when a customer repeatedly demands prompt and accurate delivery on half-baked requirements, even an agile team will take a tanker-truck of spay foam to the delivery estimate.

While the causes are dramatically different, the end result for each issue is the same. The team’s huge estimate reflects an inability to adjust and adapt. In one case the team lacks confidence in its own ability; in the other case the team lacks confidence in its customer. Regardless of the cause, these are issues that need to be addressed, as they impede far more than the team’s ability to deliver an estimate.

Sometimes a huge estimate is just a huge estimate. Sometimes it’s something much more. Next time you see a jaw-dropper of an estimate wrapped in flimsy explanation, it might be worth taking the time to find out why.