The good news is: there are things you can do. In fact, the only wrong thing you can do is supply a half-finished or empty document.

First, Ask For More Time or Info

Your first port of call should always be your boss. The time limit may not be hard and getting more time may not be a problem – you won’t know unless you ask. If the time is not negotiable, your request should also flag to your boss that you may be producing a rushed or inaccurate document.

Low Accuracy Required: Ranges

Ranged estimates are a fantastic easy solution if low accuracy is required. They reflect uncertainty (and thus risk). The less clear you are about the required functionality or work for a section, the wider the range will be, and the higher the risk will be. As mentioned last week, break down the functional areas first. Then start putting numbers to line items at the bottom and lastly tally up each section to achieve your final range.

Be Accurate Where You Can

If you still have time after you’ve defined rough ranges for everything, go back and see if you can confidently estimate fixed values for any sections. It’s totally OK to have some items fixed and some ranged. In fact, having some fixed and some ranged will help others identify which areas of the estimate are still unclear and need attention.

High Accuracy required: Assumptions

If you need to provide solid numbers but have little time or info, the only thing you can really do is make assumptions. The great thing about assumptions is that your client can clearly see what they can get for their dollar. They might be happy with section A, not need most of what you’ve listed in section B and want to add some functionality to section C but they have a starting point. That confident starting point is of value to any client.

If one of the items on your list is “ability to export data”, you may be able to comfortably provide an estimate if you assume the export is manually triggered by any user, is in CSV and will be for (say) 3 tables only. Your estimation strategy (minimalist or full-featured) will help you decide what assumptions you make

List your assumptions clearly and keep the assumptions near to the relevant section. The document will be read in order, and it makes sense that each set of assumptions is delivered to the reader while they are thinking on the functionality at hand. Because assumptions are likely to be discussed and amended, number them clearly.

Questions

If you’re unsure about the inclusion, exclusion or complexity of some areas, include a set of questions for the relevant section too. Remember the aim of this is to produce an estimate, so restrict your questions to those which may affect price, time or complexity. Asking whether your client would like their sidebar column on the left or right will probably not affect their estimate so much, but knowing if they already own licences for various required components might.

As with assumptions, keep them short, simple and numbered to help with identification and discussion.

All Of The Above

I’ve found a combination of ranges, assumptions and questions is usually suitable and quick to turn out. It’s best to check with your boss before you reach for these though, to make sure that you’re meeting their accuracy needs.

Avoid Ambiguous Language

When you’re writing assumptions or working quickly, it can be easy to write such phrases as “basic email functionality”, “modern browsers”, “flexible”, “all”, “a wide range”, “most”. Using this type of ambiguous wording will get you into trouble. With such powerful and rich free clients as GMail, expectations of “basic email functionality” could range from “send a plaintext email to a single email address with no attachments and no report of failure” to well, GMail. Contact lists, attachments, BCCs, filing, failure notifications, etc.

Saying the site will work in “modern browsers” or “all mobile devices and tables” will certainly backfire. Which version number is a modern browser? Do you want to be held to account when your site doesn’t work on the client’s nephew’s Kindle browser?

Be very clear about your assumptions.

Here’s One I Prepared Earlier!

Having a set of well maintained templates prepared can be a huge help if you need to belt out a quick estimate, particularly if your company or team specialises in similar types of projects. The more detailed the template, the better. You can drop sections and adjust some areas, but if done well, you should be able to save yourself some time by at least having those more-common parts estimated and ready to go.

Don’t Forget Risk and Disclosure

If you’re severely rushed for time or have practically no info, it’s possible your estimate and and solution are incorrect. This should be listed as a risk, and you should note your estimating approach in the document too. For example, something like “This estimate was produced from basic information and is intended as a starting point for discussions. It is not a fixed or final quote.”

Next week, we wrap up this series by looking at ways to convince your boss and your client that proper estimation is worth it.

What I saw when I entered the real world was, by and large, experience-based estimation, top down. Bob had built something like that back in 2010 and he estimated about 20 hours, so this should take about 20 too. No thought for whether the technologies, team, or detailed functionality were the same, or if Bob’s 2010 estimate was accurate. No checking back to see if the past project had any problems that should be avoided in this one. No risk assessment or description of the work.

And I saw them fail again and again.

I’m not going to give you another Solution. I’ll share what’s worked for me and touch on a few traps to be aware of, and I hope it will help.

Breaking it Down First

Break down your work from the top, before you think about time – first the broad sections, then down more as much as you can in the time you have for estimating. You can see examples of a breakdown in last week’s post.

The single most beneficial and simple thing you can do to improve your estimates is to break them down. That’s it.

By breaking it down you’re more likely to be estimating for work that you can get your head around – work you’ve probably done before. Even if you can’t estimate for everything, the smaller units will allow you to get some numbers out for those areas you do know about, or, if it’s all you need for a rough estimate, to at least take a stab at. You can then easily identify the problem areas.

Setting a 16-hour maximum forces you to design the damn feature. If you have a hand-wavy three week feature called “Ajax photo editor” without a detailed design, I’m sorry to be the one to break it to you but you are officially doomed. You never thought about the steps it’s going to take and you’re sure to be forgetting a lot of them. – Joel Spolsky

Seek a Consult

If you’re completely in the dark, don’t be afraid to consult with someone who knows more about those areas. But rather than asking “how long did it take you”, target your questions to cover your bases. What technology and version did they use, and is it still appropriate? Who worked on it? How many people? All at once or in sequence? What went wrong and what did you learn? Is any code salvageable or reusable? Is it documented? Is it stable? Do they have any warnings or recommendations? Are there any risks you should know about?

End to End

When you do break down your items and get ready to put numbers against them, estimate each one from end to end. From sitting down and opening up a work ticket to packing up. There is no such thing as a ten minute job. If it takes you ten minutes it’s because you already know the work required, you already have your environments and apps open and pages loaded, you’ve already logged your time and committed your code and updated the ticket.

Generally, I don’t estimate any line item for less than one hour of time. If I know there are a small bunch of things that will absolutely take a few minutes each once I’m ready to work, I’ll group them together in a line item with the intention that they be done together.

Who Are You Estimating For?

When you say something will take about two hours, do you mean it will take you two hours? Will you be doing all of the work?

Many advocate that the developer doing the work is the one to produce the estimate. This is great as long as it comes with appropriate measures and feedback, and it’s an approach works best if you’re in product development. If you’re in project development like I am, you don’t know who’ll be coding the project until well after the estimate phase.

So let’s say you know you can implement this line item in about two hours, your hotshot developer who specialises in this area has done similar in under an hour, and if it falls to your junior, it could take them 2-3 hours and require some on-the-job training and possibly some additional QA time. What do you do?

Excellent question! It depends on your boss, your project and how your team works. You have a few choices.

Estimate for a Junior

You could attempt to estimate for a junior, and decide if a senior is allocated the work then any time gains are the company’s benefit (the cost may increase for a senior anyway, so there may be little cost different to the client). Estimating for a junior dev is a pretty safe bet, but it can bloat your estimate – particularly if you have low expectations of your junior team (I hope you don’t)!

Estimate for the Top Guns

The project may be time critical and your boss may decide up front that your super-ace-amazing developers will build the whole thing. You could then make assumptions about higher output and lower defect rates. If you know you’ll be developing, you can probably reduce time on items like briefing and familiarisation, because you’re already all over it.

Estimate Sections for Different Skill Levels

If you charge different rates for different developer levels, you might need to take that into account when you estimate each section. You might want to give the more complex, risky sections to seniors and the safer areas to juniors.

Estimate for Average Joe

Alternatively, your company could be happy for you to estimate “average” pace (not hotshot, not n00b) and cop the additional cost if a junior team member takes up the task.

Decide on your approach before you start putting numbers to anything and get your boss on board, and be flexible enough to adopt an alternative tactic if it’s appropriate for the project.

There are two important things to remember:

1. declare your estimate calculation in the provided estimate, for each section if you need to. Make sure everyone’s on the same page.
2. when you do know who is doing what, have each developer confirm the estimate for the sections they’ll implement.

If your estimates and assumptions are off, you’ll want to know as soon as possible, and no one will know better than the dev who needs to build it.

The Zone: Interruptions and Your Estimates

So you’ve estimated that the task will take 4 hours of effort to complete. I’m guessing you’ve probably assumed 4 hours uninterrupted. 4 hours of developer utopia where you don’t get tapped on the shoulder or answer phones or emails or help other team members. I don’t know about your world, but that doesn’t happen in mine. And as much as you might say “well that interruption time shouldn’t come out of my 4 hours” the fact is that the best developers I know maintain a particularly detailed mental model whilst developing. One which begins to decay the minute they’re interrupted. It takes time to regain that and get back into the zone.

If the average incoming phone call takes five minutes and your reimmersion period is fifteen minutes, the total cost of that call in flow time (work time) lost is twenty minutes. – Peopleware: Productive Projects and Teams, on ‘Flow’

Now the great Peopleware book uses this as an illustration of why developers should work in a quiet, interruption-free environment. I don’t know if you’ll do that, but what you do need to acknowledge is that interruptions affect your effort estimate, despite your initial feeling that it would only affect elapsed time. You know best how your company resources its development team. Are your developers likely to be able to work unhindered for a 4 hour block, or will they only get an hour here and there? You know best how long it might really take you to finish that 4 hour job.

Consider factoring some of that time into your estimate, or at least noting that your estimate was produced under the assumption that work is uninterrupted.

Presenting the Totals

Many of us lose our ability to grasp numbers over a certain size. I’m the worst for it. Tell me something will take a thousand hours and I’ll look at you blankly and think that sounds like a lot of work but not be sure how much. Tell me something will take about six months and I’ll immediately have a better idea of how much work you’re talking about.

This may also happen to our clients, but on top of that, the total numbers you present will encourage expectations. Interestingly enough, the units we use to describe our totals them can affect those expectations. Saying something will take “about 125 working days” creates an expectation of delivery at around the 125 days-of-effort mark, give or take a few days. Saying it will take 6 months can help to convey immediately the amount of work involved and may subtly create the expectation of 5-7 months of effort.

Accuracy of units can be an extremely useful tool when you’re working with a rough or hastily created estimate.

I’m not saying you should estimate your line numbers in anything other than hours. But consider presenting your totals in broader units of measurement, particularly for estimates produced under time pressure where high accuracy is not required.

Pragmatic Programmer on Estimation Units

The famous software development book Pragmatic Programmer makes their recommendations above, which may help you as a guide when you’re starting out. Use what works for you. If you do find yourself with a project estimate over around 25 weeks (6 months) then consider breaking it down into separate phases and only fully estimating the first one. On such a large project, a lot could change as it progresses!

Improving Your Estimates

When your project is finished and live, go back and review the actual hours spent against your estimates. Don’t just look at the project total, but look at your breakdowns. How far off were you, and more importantly, why? Were you under because the hotshot was allocated to it, or because your rough estimate was just too roomy? Were you over because your junior got his training whilst working on your task, or because you missed some complexities?

As the one carrying out risk assessments and estimates, what can you learn from the completed project? What will you do differently next time?

Templates are Useful! Don’t Neglect Them

Have a prepared template or set of templates will help dramatically reduce the turnaround time for those urgent estimates. I’ve found that pre-populating them with starting numbers for the more common tasks is a great time saver and can help your sales team understand what’s involved in most projects too.

Remember to keep your templates up to date! Adjust your assumptions, numbers and notes as part of your post-completion project review. Even if they are just reminder notes to yourself or other estimators. You’ll be surprised at how much your estimates improve in a short period of time :-)

Resources

1. Book: Pragmatic Programmer: From Journeyman to Master
2. Book: Peopleware: Productive Projects and Teams
3. Joel on Software: Evidence Based Scheduling
4. Joel on Software: Human Task Switches Considered Harmful
5. Book: Effective Programming, More Than Writing Code
6. Smashing Mag: Effective Strategy to Estimate Time for your Design Projects

Now how do you get started on the meaty business of actually producing the estimate? Let’s take a look.

Break It All The Way Down

Before you even think about numbers, focus on what needs to be done. Much like when you write an essay, start with the broad areas then break those down into smaller and smaller sections. Aim to get down to a point where no single line item is more than about 8-16 hours. I prefer the lower end of that scale (about a day’s work) and others in our industry like Joel Spolsky work very well with the 16 hour limit when estimating.

This forces you to construct – even vaguely – a game plan, an architecture for the solution. It forces you to get your head around what’s involved and gets you past those first few minutes where the problem may seem too small (“That should only take an hour or so”) or too large (“That’s going to take weeks”). By taking the time to think more deeply on it and start describing the work involved, you may realise that your hour wasn’t enough, or that the weeks of pain can be reduced with a different approach.

Above: An example of an partly-complete estimate for a newsletter module.

Include All The Things

Because you’re responsible for estimating the effort involved in the work (and not how much it will cost, or what to charge) ensure you include it all. Meetings, planning, producing documents, briefing your team, status reports, internal testing… all of it. Based on reasonable expectations, allow effort for UAT phase(s), launch and some support after that for the inevitable tweaks and adjustments. Provide your boss and your client with the information of expected effort — they can deal with cost concerns, but at least the business understands the effort required to complete the project.

Also list any materials or fixed price elements that you know you’ll need – licences, hardware, training packages, permits etc that aren’t related to effort.

Some areas where effort can easily be forgotten:

• development environment
• briefing team members
• developer testing (testing their own work)
• opening documents and tickets and reading them
• communications – reading and responding to team and client comms
• support during UAT
• documentation (if none is needed for the client, the internal documentation is needed at least)
• etc

Remember Your Time And Constraints

If you’re under time pressure, working from the top down should help you skim over the entire project rather than only getting part way through. If you don’t get to that point where all your line items are under 8 hours, consider using broad ranges rather than providing numbers, to make it clear that there’s uncertainty there. Later in the series I’ll dive into strategies and options when you have little time or info.

Don’t Forget Risk Management

While you’re fleshing out your technical architecture and thinking about the work that needs to be done, you’ll begin to see more clearly where things could go wrong (and hopefully ways to avoid the risk). As you uncover these, add them to the risk assessment or remove any risks that are no longer an issue if you’ve changed your approach along the way.

Save Time: Use Templates

Templates for estimates can be amazing time savers, particularly when you’ve taken the time to populate them with your data. You can flesh them out with your rough estimates for common tasks, and drop in shells of sections which can act as prompts for effort commonly forgotten. The most important thing is to keep them maintained – keep your numbers up to date, if you have a project where something was missed or could’ve been done better, update your estimate document to reflect the lesson learnt so your next project doesn’t fall into the same trap.

To see what I mean, check out my preferred estimation template, which I’ve shared as a free template on Google Docs under Creative Commons licence. Go crazy!

Next week we’ll look at how to come up with the numbers.

Hopefully you produce an estimate for effort first, and the project cost and the delivery dates are worked out after that. Effort, elapsed time and project cost are valuable concepts and keeping them straight can help you and your project stay on the path to success.

Effort relates to time that passes whilst doing work on your task, and directly influences the project cost (usually proportionally). On a small task you might say you’ll invest 4 hours of effort, meaning if you sit down and work for 4 hours it will be complete.

Elapsed time tells how much time will pass before you complete the task. It influences your delivery date and doesn’t necessarily match up with the amount of effort you’ve estimated.

Let’s say that after 2 hours of work you need to wait on something – maybe if you submit your app to the app store. You know you’ll receive a response in around 48 hours and when you receive it, you can complete the other 2 hours of work. You’ve only invested 4 hours of effort all up, but from start to end of the project, 3 or 4 days may have elapsed. In contrast, you could have 4 tasks each of one hour which can all be completed in parallel. Still four hours of effort, but only an hour has elapsed from kick-off to delivery.

When you produce a project estimate, provide your numbers in terms of effort. If you know of any expected delays or sections that can or can’t be completed in parallel, communicate that to your project manager — particularly if they’re talking delivery dates with the client.

We’ll talk more about exactly what an hour of effort includes in my next post, for now we’ll focus on the differences between effort, elapsed time and cost.

Cost or Price: Sometimes Words Matter

When I say ‘cost’ I mean the dollar value charged for the project. It’s usually the sum of your hours of effort, multiplied by your hourly rate, added to any fixed costs of licences and tools etc.

If you spend more time in finance than I do, you’ll probably tell me ‘cost’ is what is expended to do the work, ‘price’ is what you charge the client, and budget is the amount of money you have available to cover the cost.

I don’t work in finance so I call it cost rather than price, and I use that term with clients as well because cost just sounds better. It implies a value which represents losses incurred by your company in order to carry out the work (though we all know better). It sounds planned, genuine, grounded in reality and therefore not open to negotiation.

‘Price’ on the other hand, is where it seems the economists and I agree: price is the sticker you put on it, it’s the amount someone is willing to pay. The implication here is that prices are arbitrary, likely to be inflated and can be haggled.

One covers costs, but pays a price. The two words carry with them whispers of implications and motive. Use them carefully.

I’d love to see the psychology or linguistics studies around it (I couldn’t find any when I hunted around) but in my experience it seems that referring to a project ‘cost’ will be subtly better received than referring to the ‘price’. If you know of any studies on it, send them through!

On Separating Cost and Effort

Sometimes there are valid business reasons why your technical estimators don’t know how much you charge clients for their time (they might leave you and go work for them directly!). Sometimes clients have different rate cards under different business relationships and the estimator doesn’t (or shouldn’t) have to keep up to date with all the arrangements.

But there are some other big reasons worth considering.

Project Discounts

In reality, particularly at the smaller business you and I do (or have, or will) work in, there are times when it’s in the business’ best interest to offer the project at a lower charge than usual. It could be to gain entry into a sought-after industry, or for an amazing portfolio project you don’t want to miss.

This is perfectly OK — good, even — as long as it’s handled correctly.

Bad companies will (if you’re even asked for an estimate) tally up the estimated effort into a total cost, reduce that cost, say 20%, to sweeten the deal to the client. They then translate that cost back into hours and expect your team to implement 100% of the project functionality in 80% of the time. It’s entirely likely that as the project progresses, they will completely forget your original estimate and hold you accountable for the project going ‘over budget’. Terrible companies will go one step further and commit to a delivery schedule based on those reduced hours, requiring you to turn out probably unachievable amounts of work in ridiculous timeframes.

This is not fiction. This is a sad, avoidable reality. Though on the flip side, projects can also be oversold and potential profits chewed up (or become a loss!) because “we have plenty of room in the budget, do whatever”.

Better companies will preserve your original effort estimate, lower the hourly rate charged (thereby reducing the cost of the project, but not the effort expected) and continue to plan their schedules according to the effort. If they’re smart they’ll be good at planning and allow slack time in the schedule to deal with issues so the expected elapsed time is achievable.

Even better companies will do this transparently. They’ll show the client how many hours are expected, show them the original hourly rate and show them the discount they’re receiving because they’re awesome. It can be advantageous to use the psychology of discounting and make the client feel as if they’re getting a good deal, which by choosing your fine self, they no doubt are.

It’s important that the choice to discount is an informed decision. Your sales team should offer a discount only once the true scope and weight of the project is known as well as the risks involved. They should never sell a project before knowing it, and certainly should never discount it without understanding what’s being given away for free and how risky the project is!

One good tactic I’ve found is to ensure that other than the sales team, all project timing and budget discussions are in terms of effort rather than cost. Even between the PM to estimator. This helps keep the focus on the estimated hours and the plan, rather than the sales decision made to discount. At the end of the day, it also changes the vibe in the team – they’ll be working focused on time rather than feeling as though their skills are reduced to a dollar figure in a spreadsheet.

If you’ve seen these mistakes being made, as a technical estimator you have a great opportunity to educate your team on how to avoid them in future.

Reusing Estimates Over Time

If you estimates work with dollar figures per hour rather than hourly rates, it will be harder for you to re-use and adapt estimates and templates over time. It’s much easier to change your hourly rates calculation on a project total than to convert line-item dollar totals into hours and then back. And if your costs have been adjusted up or down, then you’ll no longer know how many hours of effort you expected to invest in a particular piece of work.

Charging by Blocks of Time

Some companies charge in minimum blocks of time, even if it’s not all used. If your company charges in blocks of 4 hours and your task should only take 2, it’s important those two pieces of information remain separate in your scheduling system so your developers can continue onto to other work. Transparent reporting on this can also encourage your client to bundle their requests better in future. Less profit for you, perhaps, but a much happier client and more efficient use of developer time.

Key points

• measure estimates in effort (more on that how to do that later)
• inform your PM of areas affecting elapsed time if possible
• always separate effort from cost
• estimate effort before pricing or discounting the project

Gridster

A drag-and-drop multi-column grid. It’s so smooooooth!

The Best Programming Advice I Ever Got

InformIT brings us a great series of blog posts where experts share what has helped them become better programmers.

Flex

A fluid and asymmetrical grid plugin for jQuery.

5 Reasons Why Web Publishing is Changing (Again)

Thanks to @ricwrite for passing on this recommendation from @rww.

This is about allowing your boss and the client to make informed decisions, and about heading off foreseeable problems before they actually happen.

When everyone understands the potential hiccups and plans up front, a wonderful thing happens. When something ‘goes wrong’ rather than hitting the panic button, the team can calmly proceed with the plans and alternatives put in place.

The Legal Thing

Another advantage of identifying risks up front is the protection it can afford in the project contract. In the aftermath of project failure, it can be difficult for a client to question your process and preparedness when you have documented and shared the risks and impacts up front. But don’t use that as the main reason you assess risk. Telling the client it was in the contract won’t help you get the project back on track ;-)

What is Risk Management, anyway?

A risk is any factor or event that can affect: cost, schedule, quality, or attainment of project goals. Attainment of goals doesn’t just include functional requirements but also things like potential legal issues for you or your client.

Risk management is the process of identifying the risks in your project, analysing them, and treating them by putting in place a plan to avoid, reduce or accept the consequences of each risk.

Identifying Risks

OK, I don’t say this often, but it’s time to put on your pessimistic hat! To get the ball rolling, ask yourself, in all seriousness:

What could possibly go wrong?

Then list all the issues you can think of. As you flesh out your solution architecture and describe what you intend to build, you’ll uncover more risks by being aware of when you make assumptions and also by asking yourself “what happens when?”. When you know your project includes migration of content from an old system, you might make an assumption about the amount or format of data, or its quality. What happens when it’s more than you expect, or in a different format, or worse still, if there are problems extracting it for you in the first place? How will your project be affected?

Being aware when you’re making assumptions can be difficult, but it does get easier with practice! :-)

Risks aren’t limited to the development process only – if you can think of any problems in the broader scope of the project, include it. But don’t get too bogged down and spend too long documenting them all. Remember you’ll need to analyse each risk you list. If you’re struggling to think of what might go wrong, move on. After you’ve experienced hiccups on a few projects, potential points of failure become much easier to spot.

Examples of Risks

• Documents / data / content not supplied by the required dates
• Availability or responsiveness of key personnel
• Hard deadline
• Reliance on third party (e.g. custom integration may required another party to develop custom code that you need)
• Lack of confirmed requirements or input information into estimation process
• Lack of time to produce estimate
• Lack of resources / schedule clashes
• Unfamiliar third party component (if you’ve never used it, it might take longer to use or there could be unexpected issues or limitations)
• Designs produced by external party
• Indirect access to decision makers
• Junior personnel on the project
• Permission withheld to use critical third party product, service or content
• Loss of SEO ranking
• Server capabilities are insufficient
• etc

Analysing Risks: Likelihood and Impact

If you’re familiar with formal project management methodologies, you may’ve heard these described these as probability and impact, or maybe probability and severity. Different systems use different names, but the two factors represented are always the same.

Impact describes how affected the project will be if the risk event occurs. I usually rate impact as low, moderate or severe. ‘Low’ is something fairly easily recovered from after the event, ‘moderate’ requires a bit more work and may have knock-on effects and a ‘severe’ impact implies project failure.

Likelihood describes the probability of the event occurring. A risk is usually described as having a low, moderate or high likelihood.

You’ll notice that I’m not getting too specific here. Unless you want to take on massive project management methodologies and the overhead that goes with them, talking numbers and ratings and classifications seems to be a waste of time. Those calculation systems also have the disadvantage of being less understandable to the everyday Joe who could be your client reading your assessment. The ratings I’m describing are subjective, but in this realm of small-medium project-based commercial web development, I’ve found there is significant value to even a subjective analysis.

Prioritising: The Matrix

The point of analysis is to help prioritise the risks. High priority risks need attention, very low priority risks can be ignored. Prioritising risks helps the reader of your document can determine if the overal level of risk is acceptable. Once you have your likelihood and impact ratings, a matrix like the one below can help you prioritise.

Prioritisation matrix

Risks identified towards the top right need more of your attention than those in the bottom left, because they’re likely to happen and if they happen the impact will be severe. Too many risks in the red area could be an indicator of serious problems with the project and might ring alarm bells for you or the client.

If you’re not visual, a composite risk index is another way to evaluate the same thing.

Treatment

You have many options open to you as potential treatments for risks. Thinking outside the box can help a lot here. Most treatments fall into the following categories:

Avoidance

Is there a way to completely sidestep the issues up front? e.g. if there’s a problem with using a certain component, can you simply use an alternative component which doesn’t have that problem?

Reduce Likelihood

If you can’t completely avoid the risk, what can you do to make it less likely to happen? If you need to select a third party component that you’ve never used before, allowing additional time for proper research and selection will reduce the likelihood of finding problems later. If your rough schedule makes it look like you’ll zoom past a hard delivery date, perhaps it’s appropriate to recommend a phased approach which critical features delivered first. It’s less likely that come D-Day, your client will be without a system that meets their basic needs.

Reduce Severity

If it does happen, what steps can you take to reduce the impact? If your development server packs it in, ensuring there are frequent backups or source control and a well-known recovery procedure will reduce the impact of the setback. If content loading could be a problem, choosing to get started on content preparation and cleansing early could reduce the impact of any delays if it turns out to be time consuming.

Contingency (Risk retention)

Your final option is not to do anything up front, but acknowledge the risk by allowing enough time or budget to accommodate any impact. If it doesn’t happen, then the project isn’t any worse off. An example here is

This can be a hard one to use well, particularly if your quotes are fixed price as your client won’t want to pay for that component until it eventuates. When dealing with rough numbers, contingencies can create false hopes – saying “we may need up to another week if that happens” could leave you with a client optimistically expecting you to be done in a day or two. Use contingencies carefully, and make sure your project manager and your client understand what they mean.

Gamble (Do nothing)

You could choose to do absolutely nothing and cross the bridge if and when you come to it. For low risks (in our bottom left green quadrant) this is fine. In some projects and with some clients and for some risks, this is an appropriate course of (in)action for higher risks too, but not often. Even if you decide to do nothing, it’s a good habit to leave the risk assessment there as your acknowledgement so that others are aware of the possibility and of the decision.

An example

Here’s a formal, detailed example.

Risk: Design produced by external party does not meet web or CMS requirements

As (your company) specialises in web development and the CMS to be used for this project, we are able to ensure any designs proposed are workable and suitable for the project. Designs from any other source may not meet basic requirements of web or of working with the selected CMS. In addition there are specific accessibility requirements for this project with legal ramifications for (your client).

Likelihood: High
Impact: Severe

Potential impact:

• failure to meet legal accessibility requirements
• inability to meet functional or presentational requirements if design is incompatible with web or CMS
• budget overrun to accommodate changes, redesign or additional work
• schedule overrun to accomodate changes, redesign or additional work
• quality compromised if we need to force an incompatible design to work

Recommendations:

To avoid the risk:

1. Ideally, designs developed by (your company) if possible.

Or, to reduce the risk:

1. Designer to be supplied with accessibility requirements asap, and instructed to test against them prior to delivery of graphics
2. (Your company) to provide checklist of recommendations for web and CMS compatibility in designs
3. Project plan to be expanded to include time and budget for graphics testing phase. Testing to be carried out by (your company). Designer will be informed of this intention.
4. Inclusion of a critical acceptance checkpoint for graphic design. All feedback and requested changes must be actioned and delivered by that date in order for project delivery to remain on track. Designer is to be informed of this intention.
5. Budget and time increase of (X) hours to markup phase to accommodate expected issues or adjustments
6. Budget and time increase of (Y) hours to implementation of templates A,B,C to accommodate expected issues or adjustments

Risk Analysis Done, What Now?

As an estimator, it’s usually not your job to decide if the risk is acceptable or not. That’s up to your boss and the client. Your client may be happy to take a gamble on the project, but your boss may decide the risk is too high to take it on. From experience, I recommend being transparent with your risk assessments in order to set realistic expectations of both your management team and the client.

Analysing risk at the start and then forgetting about them gets you nowhere. The recommendations made in your initial assessment need to be reviewed and actioned, and your project manager needs to regularly re-assess those risks as the project progresses.

Learning and Improvement

As with most things, learn from your mistakes. When a project fails unexpectedly, look at what happened and how you might be able to identify and manage that risk in future projects. Allow your team to benefit from your learnings by sharing your knowledge. You might also find it handy to keep a shortlist of risks to watch out for, as a reminder when you’re estimating your next project.

By acknowledging project risk and making an attempt to avoid problems before they happen, you’re already on the right track :-)

Further reading

1. “Managing Project Risk is Easy with the Right Process” – Tech Republic
2. International Project Management Association
3. BOOK: A Guide to the Project Management Body of Knowledge (PMBOK 4e)
4. Association for Project Management (UK)

The Rhett and Link‘s Fake Jamaican Vacation caption fail video has been used (hilariously) to demonstrate to web developers the difficulty of providing accessible rich media on the web. But could we be drawing near the end of the CaptionFail era? In his two month internship at Google, Rio built an online caption editing tool for Youtube, greatly reducing the effort and complexity of providing captioning on uploaded video. Nice work, Rio! Full Article – The Next Web

It never gets old.

JustGage

JustGage is a JavaScript plugin for generating and animating nice & clean gauges. It is based on the Raphaël library for vector drawing, so it’s completely resolution independent and self-adjusting.

– (via codevisually)

Now that we have more devices and resolutions to support than ever, retina displays and pinch-and-zoom, scalable graphics should be high on your list of must-have’s for your next project. I love Raphaël – if you haven’t seen it yet, check it out. And also gRaphaël for presenting charts. And while you’re there, familiarise yourself with the other other options and how they compare: Web Drawing Throwdown: Paper.js vs Processing.js vs Raphaël

The way forward: what’s next for content strategy

The Most Exciting 32 Minutes in Content Strategy with @karenmcgrane http://www.cmsmyth.com/2012/08/the-most-exciting-32-minutes-in-content-strategy/

– @jeffcram

If you’re a web designer, web developer, web project manager or information architect and you haven’t heard of Karen McGrane, or if you’re not quite up on UX design or content strategy, take a moment to fix that now. You won’t regret it – Karen has a passion for her work and a wealth of knowledge and advice to offer.

12 Things I Didn’t Know About the Webkit Inspector

Flavio Copes shares a great list of little-known neat tips and tricks in the Webkit Inspector on his blog, joocode. It’s always fun to learn new things to do with one’s daily tools! :-D

50 Useful jQuery Functions for Aspiring Web Developers

Every aspiring Web developer should know about the power of JavaScript and how it can be used to enhance the ways in which people see and interact with Web pages. Fortunately, to help us be more productive, we can use the power of JavaScript libraries, and in this article we will take a good look at jQuery in action.

For those still not completely comfortable with jQuery, Sam Deering of jQuery4U takes you through 50 of the handier functions in the library. While jQuery should certainly not be your answer to everything, knowing these functions and how they can be utilised will almost certainly come in handy for you.

What We Actually Know About Software Development, and Why We Believe It’s True

Software developer, computer scientist, academic and author, Greg Wilson was new to me when I stumbled onto his talk thanks to @jeremybrown. I enjoyed it so much, I’ve since marked several of his books for reading and have also set some time aside to have a closer look at the website of his project Software Carpentry.

The Problem

Scenario: You have an ASP.NET website in IIS 7.0 that receives both http and https requests. Some people might link to the https versions of the page, but you really want Google (and other search engines) to only crawl http versions. There are relative links in the site, so you know that as soon as Google crawls one https link it is going to pick up the whole site. So as well as https links in the Google search results, you may also now have to contend with lower rankings because Google thinks there is duplicate content on the site (it sees the page in both http and https format).

You can see that Google recommends that you have a different robots.txt file for http and https, so that it knows not to crawl the https version of your site. But how can you get IIS to serve up different versions of robots.txt?

The Solution

Lets make the robots.txt file dynamic. We’ll create an ASP.NET handler so we can have .NET code in it, and tell IIS to run our handler whenever robots.txt is requested. We’ll also ensure the site still serves up other text files as it would normally.

Pretty cool, huh? :-)

The ASP.NET Pipeline

I’m assuming you know what the ASP.NET HTTP Pipeline is and vaguely how it works in IIS7.

If you don’t, here is a crash course in a few sentences. Based on file extension, when IIS receives a request it can either a) handle it by itself, or b) pass the request on to something other engine (e.g. ASP.NET) and then just hand back to the client whatever that engine responds with. In classic mode, IIS operates more or less as if it were IIS 6 – by default IIS will serve text files on its own without .NET knowing. In integrated pipeline mode IIS lets the .NET engine handle requests for all files and already has a static file handler in place to respond to text files. We’re going to tell IIS and ASP.NET to run our code when someone asks for robots.txt (in this case our code will be an HTTPHandler).

Create your Handler

In App_Code, create a class called RobotsHandler.cs, containing the code below. This example is provided in C#. There is no reason that a similar solution will not work in VB.NET but I prefer C#.

RobotsHandler.cs

using System;
using System.Web;

namespace MyNamespace {

    public class RobotsHandler: IHttpHandler {

        public void ProcessRequest (HttpContext context) {
 
            context.Response.ContentType = "text/plain";
            context.Response.Write("User-agent: *\n");
                
            if (context.Request.ServerVariables["Https"]=="off"){
                // HTTP
                context.Response.Write("Allow: /\n");
                context.Response.Write("Disallow: /MyDisallowedDirectory/\n");
            } else {
                // HTTPS
                context.Response.Write("Disallow: /");
            }
        }
    
        public bool IsReusable {
            get {return false;}
        }
    }
}

Check that your code compiles before you continue ;-)

Getting IIS and .NET to Call our Handler

Now we just need to tell IIS what to do!

Classic Mode

At the moment, IIS is still serving the txt files instead of letting .NET know about them – the request for a .txt file doesn’t even reach .NET. Let’s tell IIS to pass that request through to the handler we just built.

Get the path to the ASPX engine

First, you’ll need the path to the asp_isapi.dll for the version used by your app pool.

1. Open IIS and list your application pools
2. Double click the application pool for your site
3. Copy the path in the “Isapi or CGI Field” and cancel out of that window. We don’t want to change anything there – we just want the path.

Mine looks like this: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll.

Update the Web.config

OK. Web.config time! Add this to your web config in system.web:

<configuration>
  <system.web>
    <httpHandlers>
      <add verb="*" path="/robots.txt" type="MyNamespace.RobotsHandler"/>
    </httpHandlers>
  </system.web>
    <system.webServer>
        <handlers>
            <add  verb="*" path="/robots.txt" name="RobotsHandler" 
               type="MyNamespace.RobotsHandler" modules="IsapiModule"
               ResourceType="Unspecified" 
               scriptProcessor="YOUR ASP_ISAPI DLL PATH HERE" 
        </handlers>
    </system.webServer>
</configuration>

Don’t forget to fill the scriptProcessor attribute with that path you copied earlier.

NOTE: If you have problems (still 404ing), check out this little gotchya. Go to IIS, and click on your server (the root node in the list on the right) and in the feature view, open “ISAPI and CGI restrictions”. My version of the asp_isapi.dll was not allowed, so my web config changes didn’t work! Once I set it to ‘allowed’ here, everything all came through fine.

Integrated Pipeline Mode

In integrated pipeline mode, all requests are already being passed through to the .NET engine so we have to do even less! By default the site will be configured to use a StaticFileHandler so we’ll tell it to use ours, but only for /robots.txt.

Add the following to your web config under system.webserver:

<handlers>
    <add name="RobotsHandler" path="/robots.txt" verb="GET" 
      type="MyNamespace.RobotsHandler" resourceType="Unspecified" />
</handlers>

It’s that easy.

To make sure it’s all dandy, just check that other text files in your site are still served correctly (they should be, we haven’t added anything here that would interfere with that).

What It All Means

Basically this is saying “When a GET request comes in for /robots.txt, just pass it to our RobotsHandler and it will take care of formulating a response”. The resourceType in this case has the same effect as “verify file exists” in IIS6. If we were to set this to “file” it would check if the file is in the file system first, and if not, would return a 404 (obviously not what we want in this case!). The extra bit of work in classic mode is to bridge that gap between IIS and the .NET engine – integrated pipeline mode doesn’t need us to do that (that’s why it’s called ‘integrated’, hehe).

Conclusion

This is one technique for a quick and easy dynamic robots.txt file. There are many others. You could apply this principle to almost any file extension if you needed to have other dynamic files in your site. I hope this was useful!

Resources

• MSDN – ASP.NET Lifecycle Overview in IIS7
• MSDN – How to: Register HTTP Handlers
• MSDN – Walkthrough: Creating a Synchronous HTTP Handler
• Google – Block or remove pages using a robots.txt file

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?

The Spectrum

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.

Minimalism

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

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.

Be Understanding

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.

I’ll be touching on topics like:

• scope of an estimate
• risk assessment: AKA “how to help your project not fail”
• approaching the estimate document: how to describe the work
• understanding price, effort, elapsed time and velocity
• strategies for lack of time or info: using assumptions, questions and exclusions
• coming up with the numbers
• cost: strategies for communicating cost with vague requirements
• applying the DRY principle to estimation in the SDLC
• the argument for technical estimation: convincing your boss and your clients
• resources for further learning

Let’s get into it!

It’s About Needs

When your boss or project manager taps you on the shoulder and asks you how long a project might take to build, what does he actually need? Whether he says it or not, he needs you to supply:

• a solution
• for a price
• at acceptable risk to your employer and your client

and he wants this all provided:

• within a timeframe
• with a certain amount of accuracy.

What he has for you is input information from:

• the client – requirements, ideas, maybe a budget limit or delivery date requirement
• him (the boss) – his ideas on a possible solution
• third parties – references to sites or documents for any third party products to be used

All of this is communicated by “Hey, how long do you think it would take to build this site? It’s like eBay.” You need to understand what’s needed and endeavour to fulfil those needs.

Let’s take a closer look at these terms now. I’ll be expanding on these in later posts.

Solution

This is our technical architecture, defining what we’re talking about. Is this project to build a new website or an improvement to an old one? Is graphic design part of the project or not? Will you be loading content or is that the client’s responsibility? Can you log into the new site with Facebook or not? Will it need to work on an iPhone? The amount of detail you go into will be dictated by the required accuracy – this section could be anything from a few dot points for a rough ballpark, to a few hours of detailed reading for a formal quote.

This section is important for a variety of reasons. It’s likely to be the first sizeable written communication between your company and your client. It doesn’t mean you have to make it overly formal, but it will set up an opinion of your team and the way you work. Make it neat. Use correct spelling and grammar, even if it’s just a few lines. Now’s not the time to be shy! Harness the power of first impressions and make the most of it.

Make sure the document helps your client too – they may be comparing your response with estimates from other providers and it’s important to list what you have or haven’t included in scope so they can compare apples and apples and know you’re the best fit.

Most importantly, the solution architecture establishes expectations of functionality and defines scope of the project. The clearer you are in describing your solution, the easier it will be to detect scope creep and avoid (and at its worst) the decay of the business relationship and other horrible events later in the project.

If you’re smart about it, the solution architecture becomes your project specification when you get the ball rolling. But more on that later!

Price (or Price Range)

Depending on the accuracy required, you may need to produce a single number for a fixed quote, or a ballpark. The sorts of things you’ll cover are hours of work required by different experts in your team (or by contractors if needed), the cost of any graphics, licences, services or products needed for the project and depending on how your company works, overhead costs.

Most of us have the good fortune of not having to worry so much about the cost of a team member’s time, and can deal instead with simply giving our boss an estimate of hours required for each expert.

The most important point here (and one that many non-techs in our industry inexplicably seem to have trouble grasping) is:

You don’t know how long it’s going to take until you know what “it” is, so defining the solution must come first.

Generally speaking, if your solution is a few vague dot points, then your numbers should be few and vague (if supplied at all).

Acceptable Risk

I use the word ‘acceptable’ instead of ‘low’ because at the end of the day, it’s up to your boss and your client to each decide whether they’re prepared to take the risk or not. All you can do is help them make informed decisions by identifying risks and their impacts and (if you can) make recommendations for avoidance or impact reduction.

Time Frame, Accuracy and Input Information

This isn’t the time frame for the project, it’s the amount of time you have to respond to your boss with your estimate and it is critical that you know how much time you have before you start. Timeframe and accuracy are opposite ends of a slider: less time usually means low detail and low accuracy (or not being able to confirm that something is possible at all!). High accuracy requires more time. Both of these are also affected by the amount of info provided: too little info could mean that either you need more time to research, or the accuracy of your estimate is low in the face of unknowns. On the flip side, too much information could mean you need a lot more time to digest it all and may not necessarily help you increase the accuracy of your price estimate or solution architecture.

You Have Super Powers

In my experience a non-technical project manager can rarely do all of the things listed above with sufficient accuracy or consistency. They may have worked with a similar style project before but even a seemingly minor difference in interaction, or browser compatibility, or content structure, or expected site load will need approach and estimation changes (and new risk assessments) that our non-tech team members may not be able to identify or estimate.

As we all know, uninformed project planning leads to easily avoided disaster.

Enter you, the technical specialist. You’re probably a developer. You may or may not have a cape (you should though, right?). You could be an old hand, nailing all of this every time, in which case I hope you can provide some feedback and suggestions! Or you may be starting out in a role where you’re called upon to estimate (we all were fresh faces at some point).

Regardless of where you are in your career, your technical knowledge and skills are invaluable here. In some ways, you could even be more valuable as a technical estimator or technical project manager than a programmer! A well estimated and planned project can completely avoid many of the problems and emergencies that a talented person like you is often called upon to resolve re-actively. You know what I’m talking about.

This is your chance. Get excited about your opportunity to help craft a project that will run smoothly and be a pleasure for all involved.

Are you excited? Good. Now hold on to that until next week’s post :-P