Estimating Work and Communicating Costs

by on August 19, 2013
in book, design

An Excerpt taken from, The Value of The Finite
‘If you fail to plan, you are planning to fail!’ ― Benjamin Franklin

Estimating work and communicating the timing of deliverables is one of the most important and often overlooked skills any designer should take a hard look at developing. The art of velocity tracking ultimately determines your credibility as a designer. It’s really quite simple: If you are consistently late with deliverables, you are corroding trust with your clients, your team members, and your manager. You aren’t doing what you say you will. If you do this consistently just like the boy who cried wolf, people will stop listening to you. As a designer this can be disastrous. I can think of a number of clients that were lost simply because deliverables were late, and a conversely a number that were won-over with mediocre work, simply because it was delivered consistently on time.

Missing dates has other consequences later in projects. If you have corroded trust with team members you loose influence. Credibility as a designer is incredibly important. Because of the arbitrary and subjective nature of design, if people believe that you lack any integrity, they won’t accept influence from you. Simply handing off deliverables when you say you will, or slightly earlier, goes a long way in supporting your credibility further down the project path, and ensuring you are on equal footing with your project stakeholders.

Think about it this way; you’re the hiring client and you’ve worked with two designers in the past:
Designer A: Was mediocre in terms of talent, but reliably estimated their work, committed to a clear deadline of Tuesday the 19th, and delivered everything on Monday the 18th, according to spec with minimal revisions.

V.S.

Designer B: Who didn’t provide a clear timeline regarding how the process would work, had to be managed to commit to a date a few weeks into the project, delivered amazingly stunning designs that only incorporated some requirements, that had to be sent back for multiple revisions, putting you past your deadline, over-budget.

Who do you hire back?

Ideally you are able to both estimate, communicate, commit and deliver stellar work, but the planning phase takes just as much effort, and energy as being an effective designer.

Fortunately the solution is simple. Pay attention to how long things actually take. Here is a good strawman format to follow for most design deliverables. There are a bunch of areas where time often gets invested that designers neglect to factor into their estimates. This outline is a tool to help you avoid this and get to actual estimates that are accurate.

UX PROCESS VISUALIZATION

UX Process Visualization

O1 RESEARCH & ANALYSIS (Discovery)

▪ Customer definition and analysis
▪ Gathering, identifying, reading, and synthesizing requirements
▪ Project, planning, and scheduling
▪ User research, personae development, user workflow definition, planning, and scheduling
▪ Competitive analysis
▪ Opportunity identification and design goals

There is so much work here that designers forget to incorporate into their timelines. The first job of a designer generally is to ‘discover’ or understand everything that they can about the customer, the project, and the needs of the client/business. To internalize and make sense out of all of this information takes some time. This time needs to be factored into schedules, to set expectations early as to when an actual model or interaction will be ready for review. The scope, complexity, current state/accuracy of documentation, and saturation of the market opportunity will help determine this initial discovery timeline.

02 CONCEPTUAL DESIGN (Planning)

▪ System workflows, site-maps, or information architectures
▪ Early concepts (on paper or a whiteboard)
▪ Initial wireframes and interaction design definition
▪ Review interaction concepts, iterate, and refine
▪ Conduct hallway usability

03 DETAILED DESIGN (Execution)

▪ Visual design language definition
▪ Apply design language to interactions
▪ Review visual comps with team and sign off
▪ Formal usability testing, recommendations, and iterations
▪ Handoff for implementation

Once the project has transcended discovery into the conceptual and detailed design phase, the most common mis in terms of estimating work, is the number of required reviews and iterations required to close on a final plan-of-record design. Often projects will suffer in this phase as well without a well documented design review process to appropriately take feedback, and formalize it into design execution and closure. Again most of this work has very little to do with actual hours behind a monitor designing, and more to do with the human, and relational aspects of, sitting down with stakeholders, going through everything, taking feedback, taking notes, incorporating feedback, and communicating status on the process.

All of this work in-between the actual design effort gets left out of schedules, and projects slip. Assume reviews will be tough, multiple iterations will be required, that you won’t get it right the first or second time, and then you will either hit your date (if you’re good) or deliver early (if you’re really good.)

04 IMPLEMENTATION (Closeout)

This is also often significant time spent closing down on the projects. Writing documentation, getting assets / optimized and handed off, getting everything worked through to meet the appropriate final quality bar. Sometimes with larger complex systems, this includes incorporating customer feedback, and managing design changes into the schedule. Factor in your level of confidence into the estimated dates for your solution. Are you 40% confident or 80% confident. There’s a big different there and it will likely surface in terms of your ability to actually hit your dates further down the funnel.

OTHER ISSUES WITH ESTIMATING WORK AND COSTS

Finally there are also other reasons why projects aren’t appropriately estimated and scheduled.

Obviously all of the above is quite a lot of detail to think about, review, estimate, and plan for. Sometimes there are technologies involved that are new to the team and this causes unforeseen complications. Often there are simply risks, or unknowns when planning is first started, and if this is the case, this should be called out in the original project plan estimate. Finally clients and/or project stakeholders are simply in a hurry and need an estimate fast. The best mitigation here is to get a ball park figure to the client or stakholder upfront, and communicate that a second in-depth evaluation will be required that may increase the initial estimate. This is fairly commonplace and helps to meet the clients immediate need, while setting expectations appropriately.

Share Your Thoughts