Create an Estimation Process

[reynoldsalec]

Problem

In the past, Alec and John have thrown out a WAG (wild ass guess) after getting a broad overview of a project. There are several problems with this:

1. Leads to inaccurate estimates and inappropriate expectations.
2. Fails to engage developers, so the team who takes over the project isn't invested in the estimate and feels like they've been forced into a contract they didn't define.

Past efforts at creating a unified estimation process have been convoluted and haven't been uniformly adopted; as a result, we have multiple types of estimation sheets and no unified process that they belong to.

These issues cause Tandem to fail in reaching its goals of collaboration/transparency. It can also hurt our profits.

How do we make it right?/Automated Solution

Let's outline an estimation process that we all are invested in. This should include...

• Where does estimation fall in the sales process? (Outline Sales process and estimation's place)
• Steps for making an estimate.
• Estimation spreadsheet or other tool for outlining project scope.
• How much time should be spent outlining/estimating a project pre-contract.
• Highlighting importance of "discovery" in refining estimates post-contract (include discoveries in all our contract language).

How does this impact the rest of the biz?

Operations

Aassist in the sales -> engineering handoff, and hopefully improve our project results.

Marketing

We could potentially market our estimation process as a differentiator; other agencies have done variations on this.

Sales

This would help clarify roles in the sales process and make sales more efficient. The more standardized our sales process is, the more confident we can be in speaking to clients.

Feels and Morale

Less resentment of having estimates imposed upon developers and sales front-men not feeling like they have to wait around for a long-winded estimate process that invests too much up-front.

5. Provide a best estimate about a few things. Use the better solution to compute your estimate.

# How urgent is this?
Priority: 5

# How well does the proposed solution align with our values
Value Alignment: 10

# Story points we think this will take
# NOTE: do not set the actual story points on the ticket itself, we will use the
# points on subsequent action itmes
Effort: 21

# Value to various parts of the business
Operational Efficiency: 40
Marketing: 3
Sales: 40
Feels and Morale: 21

6. Add your entry to this spreadsheet with the above data.

@TODO: let's hold off on making this until we lock down the above a bit

7. How can we best distribute solution so it's in baked into our processes and not lost?

@TODO: maybe link to the "tie things" together part of this process

Example: We could initially add a checklist entry for the "fastest" version of this into our "starting up a new project" documentation and make sure that doc is references in all our start states so people. Ideally a lando init --source tandem command would be how we start all new projects and that automatically stands up the tickets amongst other things.

8. Generate a rough list of action items based on the above, eventually these should become action items

• Where does estimation fall in the sales process? (Outline Sales process and estimation's place)
• Steps for making an estimate.
• Estimation spreadsheet or other tool for outlining project scope.
• How much time should be spent outlining/estimating a project pre-contract.
• Highlighting importance of "discovery" in refining estimates post-contract (include discoveries in all our contract language).

9. Does anything above require discussion or feedback before this proposal is ready for primetime?

Yes! Most of the above are discussion items with a few proposed action items. We need to all feel comfortable with our estimation process.

[pirog]

@reynoldsalec for the sake of standardization im going to close this out and suggest you RESUBMIT as either a chain of tasks (if you've got a clear picture on what needs to happen) or as a "discussion" if you've like to get some more feedback

[pirog]

@reynoldsalec NM! i already discovered a better way to handle this using our new process.

I'm going to reopen this as a "note" and meta issue that needs to be refactored into our new templates

[dustinleblanc]

@pirog this was actually the subject that @mikemilano and I have been discussing. Specifically the ins and outs of what we need to provide accurate estimates. Given that I've now used the search and I've seen that this is there, should we hold off on going down this road? @mikemilano and I can work on a smaller portion of this like what we think engineering needs to provide an estimate, etc.

[pirog]

im not sure what @reynoldsalec had in mind for this but if hes fine with you and @mikemilano taking the lead on it thats fine with me, assuming that this is the most actionable thing for you guys to start working on.

if all those things check out i would start breaking this "larger initiative" down into discreet tasks (looks like @reynoldsalec already has a few obvious ones you can steal or use as inspiration) that you can chain together ideally so you guys can advance one task together a week and they can build on one another. i guess a good end goal would be to end up with an MVP or PoC of an estimation process that we can start implementing.

[mikemilano]

I'll take a shot at articulating what's on my mind here.

1. Create an outline based on a brief to full discovery effort
2. Produce the estimate based on the outline

Project Outline

What has worked well for me is outlining the project entirely before estimating. It can be a brief outline, but if there's any decent chance the project will be won, I prefer to be thorough, risking a little time up front vs losing more time and possibly reputation on the back end. Being thorough has also helped win projects as well as clients gain confidence when we're communicating detail or requesting clarification which the competition is not.

All that said, an outline can be very brief too. The pragmatic approach to a simple outline is valuable itself.

Notes:

• An outline may include these, if applicable: Summary, Timeline, Technologies, Terminology, Objective, then most importantly, organize the rest into sections and pages we are to do any work on. This is the foundation of what we need to accurately estimate.
• If applicable, we may document roles with descriptions, content types, taxonomies, or quality attribute requirements that revolve around security or performance.
• This format will become familiar, and make it easy to reason about a project
• The process of creating the outline before jumping into estimation forces a deeper understanding of the project which often exposes gaps that would remain "unknown unknowns".

Estimating

Now that we have gone through what will become a familiar and reliable process of understanding (and communicating) what it is we're building, including the risks, we are in a much better position to start putting down numbers.

From here, we can go 2 ways:

1) The most simple approach would be to put numbers to each of the pages, features, & quality attributes, along with other standard project costs.

2) Use the Lullabot estimation worksheet that Dustin introduced which averages the estimates of 2 developers and has risk variables built in. (i.e. for each item you provide a "confidence" level. )

Based on our experience, going straight to this worksheet can be messy from an organizational and detail standpoint. It's very difficult to reason about the project as someone being asked to put estimates down. There's no context outside the cells.

This is where the outline will help tremendously, especially for more complicated projects.

• Anyone we ask to provide estimates can get an understanding of what they are estimating from the outline.
• We can organize the line items as they are in the outline, or partition it into more granular components based on our better understanding
• We can refer to detail in the outline from the worksheet, so we're not limited to cells for detail

[pirog]

I love everything @mikemilano has said above. 👍

[dustinleblanc]

The combination of the two items is what seems to be the magic here. The project brief/summary gives a very holistic and top level view of the project while the spreadsheet becomes the granular "checklist" of requirements.

I think I've noticed that the limitations of the spreadsheet are mostly surrounding the formatting of information for consumption by the estimator. The cells are tiny and don't leave a lot of room for explaining context.

The interesting bit about this is that a spreadsheet with it's visual/reading short-comings isn't required to derive the value from the wideband-delphi style process, we can use HTML to do that eventually.

[reynoldsalec]

In talking with @mikemilano this last week, it seems like the estimation process needs to be put into context in the sales process. Asking an engineer to create an estimates for requirements they aren't really familiar with is difficult and can extend a sales process that needs to be 1-2 days into a 3-7 day process. We had discussed something like this:

1. Point salesperson does initial qualifying sales call with prospect. [Qualification Sheet + Initial Project Brief]
2. If the prospect qualifies, salesperson and an engineer do a follow-up call for requirements collection [Estimation Sheet + Refined Project Brief]
3. Write a proposal [Proposal Format]
4. Send an invite to the client for a meeting to review the proposal together (engineer optional).

This process seems to maximize exposure to the project reqs and should ease the handoff into development without wasting undue time.

[serundeputy]

In general I am in agreement with the ideas being expressed here;

• 1 to 2 day turn around on proposal + estimate
• estimate includes
  • project outline / project brief
  • estimate spreadsheet based on project brief w/ line items matching project brief sections
  • line items may be broken out for more granularity of estimates if engineers have obtained more context via the process

One thing that i've not seen mentioned here yet that I have done in the past is sell the client an 20/80 contract where after the 20% we deliver the client a detailed:

• Project Brief
• Technical Implementation plan
  • sometimes they can pick and choose from this a la carte to flex the price point/timline based on which features the choose, add, or eliminate

At the point of this 20% deliverable (the client pays for the 20% time), but then they can hire us for the 80% complete the project or take the discovery to someone else or discard it whatever they want the deliverable is theirs.

This process gets Tandem payed for a detailed discovery and estimation process. Produces a tech spec for the client that has value to them beyond us. Allows the client to pivot once they see a detailed breakdown of features in time and money. Most of the time they client appreciates the detail and info they can give to their boss/board and hires you for the 80%.

So the sales part would be the 1 to 2 day effort that @reynoldsalec layed out. Then the client can choose to pay for the detailed analysis or not.

[mikemilano]

I like what @serundeputy is suggesting here as the product of what we produce during the initial estimate for projects that warrant it. I like how it normalizes an approach towards a detailed discovery.

This reminds me we, our initial estimation effort should not be considered lost. We should price in the discovery and architecture that happens as a byproduct of the estimate so we make it back if we win the contract.

This helps justify putting a solid effort into being thorough on an estimate based on the risk/reward. The initial time spent is risk, but if the reward warrants it, customer confidence rises as they recognize more thorough attention and effort. It's opportunity to set a great first impression as they get a taste of how it is to work with us.

[pirog]

@reynoldsalec seems like a lot good notes in here. Do we have actionable tasks spawned from here yet? If we don't can you spin some up so i can close this down?