Without detailed requirements from a client, one of the most valuable ways a project manager can help an estimator is direction on what to include in (or exclude from) the solution. I’m talking about scope here, and your strategy during solution architecture and estimation is crucial. If your approach misses the target, your estimate will crash and burn and the project may never proceed – not with your company, anyway.
If you’re fortunate enough to have a detailed (and cohesive) project requirements document, your estimating approach may already be selected for you. You’ll simply describe the implementation of what is already listed. But even then project requirements aren’t always thorough, and you might find gaps where you’d normally expect functionality to exist.
So without detailed requirements, how do you decide what features and functionality to put in and leave out of an estimate?
Tailored minimalism is at one end, custom fully-featured über solution is at the other. Most of the time your project is somewhere in the grey area between. Having some idea where you need to be will help you write an estimate both your PM and the client are happy with. (Which means less reworking!)
Technical estimators (that’s you!) are in a great position to identify potentially valuable features at low effort. Anticipating the needs of your client shows you’re trying to understand their business and dentifying low hanging fruit could set you apart from your competitors by providing added value, making your estimate (and your company) more attractive.
“They’re a bit more expensive, but we get all of these extra reports and an export. They were interested in us and even had a great idea of building this tool…”
On the flip side, if you know your client is strapped for cash or has a hard delivery date and is highly flexible on functionality, you’d be wasting your time (and theirs) by including unrequested sections in the project. Including too much functionality could quickly put you out of their price range or make it seem like you’re not listening to their needs.
If it’s not clear what approach is required, sometimes it’s best to just ask your boss or the client. Explain that you aim to succeed and talk about the differences between the two extremes.
This mindset requires you to justify each piece of functionality included. Only the critical makes it through. Is it really needed? Really? Is there no alternative?
The best minimalist estimates are fed by a short list of clear and simple requirements and time or budget limitations are the key factors.
Think outside the box. Don’t get stuck mulling over details of implementation on the site but rather think about the client’s business and whether some processed could be done offline or utilising other services. Finding smart ways to cut out functionality can be fun :-)
Examples here are:
- Is a CMS really needed, or will a static website be sufficient?
- Can payments be processed offline, maybe over the phone or on delivery?
- Do they have web-savvy members of their team (or can they be trained)? Can content be prepped offline rather than resizing images and cleansing text on input?
- Can pdfs of content be uploaded manually on the rare occasions that content changes, or do PDFs really need to be generated for each page?
Remember your client might be happy doing some things manually that you’d turn up your nose at. They may also be happy to implement those features at a later time.
Minimalist projects don’t typically have much room for experimentation so proposing a technology or tool that is unproven may not be the best idea here. Keep your risks down in order to keep client satisfaction (and your profits) high.
Anticipating needs can be difficult at first but becomes easier with experience and exposure to more projects. In contrast to the minimalist strategy above, here we think about what isn’t mentioned in the required functionality and might mean manual processes for the client. What are features – particularly features requiring little effort to implement – which may make life easier? Suggest these as possible inclusions, something which may help the client save time and money in the long run. Consider the longevity of the project and events that may happen over time.
The best full-featured projects come from clients with larger budgets and long-term goals who are intent on establishing a working relationship with you. They talk about meeting long and short term business needs. The main driver is pursuit of a solution benefiting the business.
It can be fun to come up with cool and helpful ways to save the client time and money. And they’ll love you for it.
Simple examples are:
- Reports and data extractions (a common one is exporting data for MYOB or other financial packages)
- Maintenance of data published on the site but owned by other systems. Is a synchronisation tool required?
- Smart contact forms, directing enquiries to specific people in various parts of the business
- Search auto-completion and misspelling suggestions
- SEO and social media strategies
You may not include all of your ideas in detail, but listing them for discussion can be advantageous.
Things to Watch Out For
Don’t Dump the Important Stuff
The strategy you employ affects only features and functionality. It doesn’t extend all the other stuff that needs to happen in a project. If you’ve been told to be zen, don’t drop your testing phases. Your planning, processes, management, quality assurance and infrastructure work all still needs to happen.
Your estimating strategy is a strength. Don’t use it to undermine the quality and profitability of your project before it has begun.
Sometimes there are forces within your team that for whatever reason push to keep the cost of the project down. It’s your job to stand your ground on these important parts of your project and processes. Later in the series I’ll provide you with what I hope are some useful ways to do exactly this.
To use either approach very well, you need to make an attempt to understand your client and how things work for them day to day. This is a great thing. Understanding your client will help you both during the course of the project and will produce a better result. But don’t get carried away. You don’t need to work as a clown for a month to estimate the construction of a circus website. For a ballpark estimate it can be enough to care a little and take a moment to think. If you’re not sure how parts of their business work, talk to them or include a few questions and suggestions with your estimate.
Regardless of whether it is minimalist or feature-rich, the solution you define should help them and their business.
Watch Your Time
Be mindful of the time you have to produce the esimate – if there are lots of things that could be added, you’re probably be better off listing a few quick questions and suggestions like “Are any reports needed?” rather than fleshing it all out in a detailed estimate first.
Being Clear About It
Your estimate document should state up front which estimating approach was used and why: a minimalist approach including only critical functionality to satisfy requirements for hard launch date. Or a full-featured solution to best meet the immediate and long term needs of the business.
If you’re including items not explictly requested then it’s a good idea to mark them as such, so the client and project manager can easily slice them out if they’re not needed. If you’re putting functionality into the “culled” list but aren’t sure, declare your assumptions so that your project manager and client know exactly what you’ve cut out in case it’s needed after all.
I’m a fan of transparency and I think cultivating a open communication with potential and current clients is a great habit to get into. Remove the mystery from the estimating, architecting and building processes and you’ll be educating your client on the value of your expertise while encouraging them to be engaged and adaptable.