2

Two months ago, I joined a software development company. They have just assigned me my first big task that consist in overhauling all the front end of one of our Rails apps. The project is still in the design department, but I will start to work on it soon.

The problem is that management asked me the typical "when you will finish". The truth is that I have no idea. Writing the HTML and CSS is not really complicated, but the controllers are a mess and I expect to discover lots of problems.

In this two months I've seen quite a lot of peers sleeping under the desk - this is Japan - and this is something I am obviously not going to accept, so I want to make the risks clear before even starting.

This is what I thought I will write once I get the definitive design:

Project: Redesign of X app.

Scope of the project:
- Write all the templates of the new design using HAML language: X lines of
  code affected.
- Write all the new stylesheets using X framework: X lines of code 
  affected.
- Refactor controllers and correct possible inconsistencies: X lines of 
  code possibly affected.

Description of tasks:
- Page 1:      x hours est.
- Page 2:      x hours est.
- Page 3:      x hours est.
- Component 1: x hours est. 
...

Total estimation of project duration: XXX hours.

Risks:
- This is the first time that we replace all the front end of the
  application. All the estimations have been done without having a 
  real example to compare, but when we added Page5 and Page6  in the 
  Issue #xxxx, took x hours work. This is the metric I am using to predict
  the duration of the tasks.
- I have detected some issues in the controllers' code that will necessarily
  have to be addressed while performing this project. Other unknown issues
  are expected to arise.

For this reason, I predict _high probability of deviations_ on the original
estimation that I think should be taken into account.

Appart from the awful grammar (feel free to edit), is there any other point that should be added to this document?

Also, this text just came out of my head, but I am sure that there are methodologies that are already being used in other companies. Is there an standard way to communicate estimations? Or does this document has a name in Project Management?

Note: This question is cross-posted from Workplace because I didn't know the existence of this portal. Please, tell me if there's any problem with that.

3

Oh boy, there are a few red flags in your story (some of them you've already identified yourself). These are the big ones I see:

Management asked "when will you finish"

That's somewhat great: they ask you. That's half the battle. However, if they're asking with that wording, they are asking for a promise, which is very different from an estimate. Managers tend to do that, leading to some kind of "negotiation" with their own employees. Whenever you communicate with them, be clear and distinguish between estimates and promises.

I've seen [peers] sleeping under the desk [...] this is something I am obviously not going to accept

To me, that's a sign of Death Marches (recommended reading), and not sustainable. It's good that you realize this. Be strong on this one, for your own sake/health as well as the project. On a side note, ask yourself whether you want to be in this kind of environment at all...

Redesign of X app.

Uh oh! In my personal experience, nothing is as hard as re-doing an existing feature. Joel Spolsky wrote a quite worthwhile article on the subject a few years ago, basically saying you should never rewrite a product from scratch. A nuance not easily found in the article is that you can start off a project to create something to compete with the existing product.

The reason I mention this is becaues developers and their users/managers tend to ask when the rewrite-project is done, but include the impossible requirement "And it has to do at least everything I could do with the old version.". This'll make it impossible to give estimates, if not even impossible to finish the project.

Instead, write about your project as a new product that'll compete with the old one. Any feature for the new product has to be explicitly mentioned. Only that way can you estimate with some confidence.

Is there an standard way to communicate estimations?

Yes. There are many. Most currently popular ways come from Agile methodologies. I highly recommend reading Agile Estimating and Planning. Some of the key points:

  • Estimates will be off. You and your manager need to accept that. They will be off by a lot early in the project, as much as a factor 0.25 - 4.00. This is known as the Cone of Uncertainty. In other words, if you estimate it'll take you 15 weeks to complete the project, it might in reality be 60.

  • Iterate and re-estimate. The best (perhaps even only) way to get better estimates is do some of the work and then re-estimate. Doing the parts with many unknowns as early as possible will help reduce uncertainty in estimates. Re-estimate often (e.g. after every iteration) to include new information. Communicate these re-estimations a.s.a.p.

  • Estimate in relative feature-size (e.g. "Story Points") first. This is easier than estimating in "man hours" or even "time left". Then do some work for a few iterations, and determine your "Velocity" (number of story points you can do in an iteration). If you have to you can combine your velocity with the number of story points left for a release to estimate when you'll be done.

  • Know why long-term estimations are required and include a margin of error accordingly. If the PR team needs to create a big campaign for a certain date, or if HR needs to schedule a company-wide training, there are external deadlines coupled to your estimates. Because your estimates will be off, you need to include a margin for error. However, if the estimates are neede to assess whether it's "worth it" a less precise estimate may be required.

  • Give bounded estimations, for example "the project will take 100 - 250 hours". Use this to introduce the cone of uncertainty to your managers, and convince them to let you work a few iterations on the product, so you can give them more precise estimates.

But wait: I haven't quite answered the question yet...!

The actual question you have is about a standard way to communicate estimations. You even include a format you'd currently go for.

First up, a lot of my text above can be summarized as these directs points of interest in your current setup:

  • A high level / one-page project description is still great, though perhaps not for estimations and feature lists;
  • Don't talk about "Redesign", instead focus on a "New Product X" (that coincidentally does a lot the original product does as well);
  • Setting a Scope seems like a very smart thing to do (though you may want to call it "initial scope", as the business people can and should change their mind along the way, be it at a cost);
  • "Description of tasks" I'd replace with a high level overview of features, but whatever you do leave out the hours estimations.
  • Don't include a total estimation here, unless you directly refer to the other docs (see below);
  • The "Risks" section is great. You can add the suggestion of doing that work asap, so you can asap change directions or cancel the project if needed.
  • Don't go on the defensive like you do in the last part, but instead (a) be clear in your docs that you estimate and not promise, and communicate outside informally what you feel is the difference between the two.

Now, to finally answer the question, the standard way to communicate estimations I'd recommend:

  • Utilize Story Points (or similar construct) and Velocity to convey estimates;
  • Create a Product Backlog for a high level prioritization of features;
  • Create a Sprint Backlog for each iteration with the next few product backlog items to work on;
  • Create a Burndown Chart to show progress and estimated time left;

Most Agile methods (and Scrum in particular) have the above artifacts in one way or another, and I highly recommend using those for your purpose.

Again, I recommend reading Agile Estimating and Planning because it basically is a long answer to your question. It introduces all of the above artifacts quite clearly. Searching online for those tools will also help.

Good luck!

  • Wow. I am amazed with your answer. Thank you very much for taking the time to write such a comprehensive text. I just ordered Agile Estimating and Planning. I have a big task to do trying to implement Agile in my team! – Daniel Feb 8 '16 at 13:44
  • @Daniel No problem. Coincidentally, I had just realized I didn't answer your actual question all too directly, and will add some more details on that to my answer. (But what's there should hopefully help already.) – Jeroen Feb 8 '16 at 13:46
  • 1
    you gave me the rod instead of the fish! ;) – Daniel Feb 8 '16 at 13:56
3

Even before agile we had a concept called "Order of Magnitude Estimating". It's a tool that has been pretty much forgotten, in large part because companies are so date driven, to meet quarterly stock reports or other regular "status" checks.

@Jeroen provides some great mechanisms to get better estimates and I support.

And at the same time you need to change communication to management. Try and bring them back to what an estimate really is, an educated guess.

Range: So the very first thing is never give a single date. Instead give a realistic and pessimistic date. Never give an optimistic date (the one where everything goes right, because it never does).

Estimate and then Velocity: When you do give the estimate range you say something along the lines of, "Here is an initial estimate, based on what we know now. This estimate is at best 50% accurate to hit in this date window." Then you go on with "To get a more accurate sense of when we will be done, we need to break the project up into small deliverables (Agile) and measure our actual progress. A quarter of the way into the expected project length I'll report a projected delivery date that is based on actual work completed. This will be 70-80% accurate. And halfway through the project we should have enough data to get a 90% or so read on our actual completion date.

This is how we should be doing Scope driven projects. The reality of course is a bit harder. We've got forty or so years of people taking Estimates as Commitments and we need to start changing this back. It can be done, I've been doing it in the organizations I work for. It takes constant communication.

Here is a link to a PowerPoint deck I use when educating teams and management on this challenge. Scope vs. Schedule in Agile. Feel free to use this.

  • Thanks for your answer and for the link to the presentation. I should definitely make a presentation my self soon. We should change the Red Bull Driven Development for something more healthy for everybody. – Daniel Feb 8 '16 at 13:50
1

Most people to whom we provide our deadlines do not care how we arrived at them. They want a date certain when you will deliver and that date becomes largely unmovable.

Those that you have estimating the work need to provide their work and duration estimates in a best, worst, and most likely values, so that you can understand the range of probabilistic results as you summarize these values to the project level. Since you have so much uncertainty in the work, you need to use the planning values on the outside of that range, like P80 or P90. Therefore, you will have a lot of contingency built in your promises.

You also need to document very clearly the planning assumptions that went into the P80 or P90 planning value, such as the size and skill mix of the team you expect to have, the behavior of external dependencies, etc. I don't think the risk that you have not done this before will resonate. You need to break this risk down into smaller drivers that I think will sell more. The ultimate outcome of identifying the risk to sell the need for a bit of contingency reserves, so that if even your fat planning value starts to fail, you have something to fall back on.

Finally, it is very important you have a solid way of measuring progress so that you can report early and often any unfavorable variances to avoid surprises. This is hard to do because no one really wants to express bad news and no one wants to hear them. You have to get past that.

  • You are true that we I should work more on the Risks section. Thank you David! – Daniel Feb 8 '16 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.