Category: Quality Product

9 Deadly Sins Causing Your Software Estimates to Fail

(6 minute read) – Estimating technical projects is difficult. Tech is expensive and complex. I’m guilty of so many mistakes. Learn from me.

Steven SilveyLeave a comment

“What’s the level of effort?”

The dreaded question.

School taught you how long you could procrastinate before starting an assignment…and then starting just a bit beyond that point. Early on, it’s an innocent enough question. Those with a few wrinkles on their head know the underlying evil associated with The LOE. My team gets a good chuckle when I skim over their technical explanations and then not-so-subtly request, “So…what’s the level of effort?” They see me as a developer no more.

Developers tend to work on projects for a fairly long time. As time passes, passionate, devoted developers become personally invested in projects. They want to see it succeed and do well. Projects are like a relationship and estimates are the first impression. Nothing saps a human being’s spirit more than a volatile project built on a poorly constructed estimate. Let’s look at several common offenses that can doom your project from the start.

1. Rushing
We live in an age where technology is being pumped out. We, the tech industry, have set the precedent of high competitiveness and capability to build quickly. So are we really surprised that our non-tech coworkers have quick turnaround expectations on estimations? Doing an estimate the proper way without commandeering others’ busy schedules takes time. And, typically, tech projects require the largest piece of the pie. So why not slow down and do it the right way?  Rushing makes you miss important details that will haunt you later on.

2. Sloppy or nonexistent requirements
Technology does not infer anything; every logical step is explicitly instructed to execute. The more ambiguous a project is defined, the greater risk the project will miss the target and/or vision.

Sometimes requirements have to be left open to allow creative flexibility during the design phase of the project. If that’s true, tech needs to be re-estimated afterwards or aimed unnecessarily high upfront to compensate for the unknown functionality that has to be implemented. Let’s not mix goals/desires with requirements.

I had a good Dilbert comic strip to share here, but I didn’t want to pay the license fees for it.  Just google “Dilbert Estimate” and get quite a few “I’m laughing because it’s true” moments.

3. Weak assumptions
One would think the contract defines what you are going to do and if not explicitly written, it’s an easy discussion. Wrong. The funny thing about words is people imply so many things from them. Having to explain your estimate didn’t account for something because it was not explicitly written and your stakeholder thought that it was covered is still an unpleasant conversation. Suddenly, your client either feels like they had been deceived or they feel ignorant for not understanding. That’s not the goal! You’re setup for success if they are setup for success. Get into their head and write down explicit assumptions that protects your scope and their integrity.

4. Forgetting Life
Bathroom breaks, vacation, administrative work, emergencies, etc.. Life happens (a common theme of this blog!) and to not figure that into your estimates and timelines puts one or all of your goals at significant risk. Tech is expensive and many forces want to cut down estimates, but neglecting to consider incorporating contingency hours is eventually going to cause the train to go right off the tracks.

5. Shotgun Estimating
Building a large project in haste without proper planning or requirements (see everything above) in the hopes of it sorting itself out during the course of the project has historically not worked well in my experience. Large buckets of money can disappear very quickly when you get deep into highly complex software projects. It’s better to break projects down into more consumable portions and put down wide ranges for the future phases noting that they’ll have to be re-estimated once you get the current phases done. If you’re dealing with a large budget, start breaking it down into milestones as quickly as you can. Continue the estimation phase even if it’s already done.

6. Percentages
Using percentages is a crime. It’s an insult to the people who have very real, day-to-day, time-consuming objectives throughout the course of the project. Every resource should have X amount of hours for each and every task they are planning to do. At the end, you want to compare how close you came in on each task. You gain nothing from a having a resource that’s 15% of some arbitrary number.

7. Going Solo
I have my weaknesses and my strengths, as does each and everyone on my team. The strongest estimate is one that is done divvying up the various tasks to best fit the team’s strengths accordingly. If you are filling in hours for another resource or team, you could be greatly missing the mark. Let them have a say and furthermore, let them take ownership of hitting/missing their hours. If they miss the random hours you put in, it’s really easy for them to put the onus on you.

8.Estimating in Silos
Estimating processes often turn up like Jr. High dances: no one goes across the room to talk to the other side. Stop that. Gathering details of what creative, UX, strategy, marketing, copywriting, etc. are envisioning can only help your team bolster hours to ensure they can meet the expectations. Also, providing feedback to those other disciplines can shed light and make them compromise accordingly to ensure a sound scope.

9.Taking it Personal
Estimates are always negotiations. It amazes me how many people get personally offended when their hours are questioned. There needs to be push and pull for the betterment of you, your team AND your stakeholders. Don’t let this drag you down or threaten your numbers. A reduction of your hours should always come along with stronger, more limiting assumptions and requirements. You need to take this hardline stance to ensure your project’s success.

Summary
I was taken aback a few months ago when I was complimented on how well I do estimates. Quite honestly, it’s hard to feel like this is a skill given how non-scientific it is often approached. Nonetheless, I’ve refined my approach through countless experiences and missteps. I’m guilty of all the “sins” above. I’ve tracked all of this closely and made sure to learn and grow each time. The one thing I know is estimates are often a very, VERY small portion of the overall project and doing them wrong can make long, drawn out projects incredibly taxing. It behooves me to fight the good fight up front no matter how unpleasant any conversation may be. Because a good estimate often leads to a happy team, satisfied stakeholders, a quality project and a reasonable budget that can be done within a reasonable time.  You’ve heard this before.

Four Simple Goals of the Desired Project Manager

Steven Silvey2 Comments

When I switched from a team member (i.e. “developer”) to a team leader (i.e. “TPM”), I really had to think about what value I bring and how I can excel at this role.  I no longer needed to get in the weeds of tracking down a race condition caused by a multithreaded solution or how to properly validate a form in ASP.net.  I took a walk to clear my head on a sunny, summer day.  I remember the cool breeze.

Listening to the ambient sounds of nature, I thought about why I was here.  I thought, “I want to leave work each day feeling like I brought needed value, did the honorable thing and helped my team succeed.”  This has made my life much more fulfilling approaching work with this mindset.  The big challenge, the dumb question, the personal problem, the tedious task…I would respect it all and give each my full attention.

But that’s a lot of stuff.  It’s not really well defined either.  What do I need to do to make sure I am the team leader my team needs me to be?  Back at my desk, I broke this down into four simplified, overarching daily goals:

1. Make the Team Happy
If you want your life to mean something and contain as much happiness as possible, is it so hard to believe that each and every one of your team members also want the same thing?  Do not underestimate the value of a happy team.  A happy team wants to work with you especially if they see you fight for their happiness.  It can be as simple as minimizing external distractions or being a soundboard for their various frustrations.  Or simply allowing yourself to be the butt of a joke.  People have bad days all the time, be able to respect that and motivate your team forward without adding to what’s already got them down.

And bring donuts from time to time whether you have a reason to celebrate or not.  Never lose the pulse of your team!

2. Ensure Stakeholders are Satisfied
My first thought was to say “Satisfy the Client”, but that comes off cold.  That sounds like an artifact of my old development days.  I rather like the broad stroke approach of “Stakeholder” as defined by the PMBOK.  Thinking this way makes me care just a little bit more about my project.  Consider some of the following groups:  your main client contact, other clients within other business units associated to your project, the people who use your software, your technical leadership team and so on.  Anyone who cares about your project such that its success has a direct impact on how they perceive you is your stakeholder.  Might want to read that one again!

Also, if you are keeping them satisfied that typically generates more opportunities for you.  You work hard each day (…right?), receiving a hint of their satisfaction gives you a much-deserved (…right?!) sense of accomplishment.

3. Create a Quality Product
Quality may be the underlined word in this objective, but don’t skip over the “Create” portion.  What is more validating as a human being than being able to create something?  I could spend a lot of time discussing “quality”, but it basically boils down to everything.  Everything about your product matters, from the color and placement of the cancel button to increasing sales to optimizing algorithms that speed up the application.  Everything.  And just because your hands aren’t in the clay as a developer or designer, you are still very much a part of the product’s creation, guiding the vision through implementation to deliver what a business both wants and needs.

Maintenance is a part of the product too.  I said “everything”, right?  If anything, maintenance is imperative to sustaining/improving a product’s quality.

4. Deliver On Time and On Budget
The above three goals are like the golden rules of being a good project manager.  But, quick sidebar, what happens when two elderly women in opposite directions fall at the same time?  You can’t help them simultaneously.  Number 4 brings us to reality.  We only have so much time and so much budget to work with.  If you can accomplish the above three goals and deliver your product by the deadline without going over your budget…I’d call you a successful project manager.

So you will have to make some hard choices and figure out how to maintain the above three goals under increasing limitations and pressure.  I find prompt honesty and transparency are the keys here.

Also, don’t find yourself simply laughing at the two elderly women who have fallen and can’t get up.  That’s just ineffective…and mean.

Summary
On my morning commute each day, I tell myself:  “Happy Team, Satisfied Stakeholders, Quality Product and On Time/On Budget.”  It’s a simple thing to remember and guides my energy in a way that influences my projects positively.  Throughout the day, I pause and ask if what I’m doing is actively pursuing these goals.  Challenges will occur and these metrics of success can often conflict with each other, but as long as I don’t lose sight of the project holistically, keeping these goals in mind, I can shape the project as a success and in turn be successful myself.