Software Estimation: How To Do a Rough Order of Magnitude

Here’s the best software estimation technique I know; it’s not as good as doing proper Planning Poker and then measuring your actual velocity, but it’s a pragmatic approach if you are forced to come up with a time-based estimate for political reasons or to support sales activity.

I suspect other people use this process or one just like it – no idea what they call it, but I tend to refer to it as a “Rough Order of Magnitude” or ROM.

At first glance it looks pretty straight forward and semi-obvious, but, like many things in life the detail is where the important stuff is.  So lets start with the main steps then get into the detail:

  1. Design the system:
    • On a whiteboard / paper.
    • Decomposed down to a reasonable level of detail.
    • Make a note of all related tasks (e.g. environment set-up), plus any assumptions and constraints.
  2. Do two estimates:
    • For each and every part of the design: “best guess” & “worst case”.
    • Include all the related tasks.
  3. Write-up.

Design the System

The objective here is to come up with a design that should work, and then identify each and everything you need to do to build it.  Effectively you’re aiming to design down to the module/component/widget level.

For example, if you’re building a webpage that searches a database this implies that your design will include:

  • A database.
  • Tables in the database (do know what the schema is likely to be?).
  • The tables will have to be query-able (so will you write Stored Procedures?).
  • And so on.

Here’s some real-world examples of the kind of thing you’re after:

As you go through the process of coming up with the design you’ll be making assumptions, working within constraints and coming up with questions that influence the estimate – make sure you note these down.

Other tasks – things that aren’t part of the solution but will be part of the work/effort in delivering the solution; make sure you note these down as well.  For example:

  • Setting up development environments, source control, etc.
  • Setting up development servers, databases, access to them (permissions), and so on.


Once you have the design you need to go through each module/component/widget and every task, and for each of them you want to come up with two estimates:

  • Best Guess – the shortest amount of time it could possibly take.
  • Worst case – the longest amount of time it could possibly take.

For example, let’s assume you needed to deploy part of the solution to Azure (or AWS) – but you have never done this before:

  • Your “best guess” might be half a day:
    • Because it’s only uploading  a package, how hard can it be.
  • Your “worst case” might be 3 days:
    •  Half a day just to login because the details you get given will be wrong / the account will be the wrong type / you won’t have the level of access people said you’d have, etc.
    • A day to do get hold of a test package that you can actually upload, plus all the research and reading you’ll need to do to figure out what it is you actually need to do, maybe even some time to do some quick prototyping.
    • Half a day to refactor your configuration options and redo your build so that it will now work based on what you just learnt.
    • A day to actually upload it and then figure out how to verify you’ve done it successfully.

As you might have figured out, the best guess estimates are where you can be an optimist, you can assume all your assumptions are correct, you’ve successfully mind-read the clients intent, there will be minimum defects, you’ll have no security / permissions issues connecting to the server the first time, and so on.

With the worst case estimates you do the opposite: feel free to take a hard line on stuff, assume your assumptions are wrong, that the data will be far more complex than you hoped, that the test data you get will be of really poor quality, and so on.

The key thing is to keep the estimated grounded in some rationale, that’s based on your experience and can be justified.

If you’re working on a whiteboard, just put your estimates straight onto the design (use a different colour).

Use any unit of time you like that makes sense (hours, days).

The significance of two estimates

This is one of the more subtle but powerful aspects to providing two estimates: the bigger the difference between the best & worst cases, the more pronounced the risk profile. This can apply to the overall ROM but it’s especially interesting at the task/component level. Consider:

  • You’d expect relatively larger items to have relatively bigger estimates – and a relatively larger best/worst range.  You might not think this means a greater level of risk, but remember that Planning Poker specifically uses a number scale that rapidly increases in size; the reason for this is that larger items are inherently harder to accurately estimate.  To me, this means they automatically attract a higher level of risk.
  • Ignoring the sheer relative size of an item, a bigger best/worst estimate probably suggests you’re less sure about the nature of the item, that it has more assumptions and unknowns.  All reasons to consider it to be a greater risk.

Once you’ve finished the initial estimation of all items and tasks, review those that have abnormally large best/worst estimates.  can you break them down into smaller pieces?  If not, discuss them and note down any risks and assumptions you identify, and include these in the write-up.

As a team or individual

I have taken this approach on my own, but usually it’s as part of a small team – e.g. if I’m the solution architect on the project and we get given a new major feature to estimate.  I’ll take a few of the key developers into a room to thrash it out.

As per Planning Poker, estimating as a group is always better, specifically:

  1. Estimates arrived at by consensus are usually more accurate.
  2. Others will spot stuff you missed, and a fresh pair of eyes is always good.
  3. It’s way more fun.

Going further, use the other tenets behind Planning Poker:

  • Avoid cognitive bias / anchoring – i.e. when discussing the system, especially when you get close to estimation.
  • Let everyone think of their estimate before people start revealing their own.  Because you’ll be estimating using actual hours or days you can’t really use a card-deck, so you’ll probably just have to rely on people being honest and not privately changing their estimates when they hear someone else’s.  Adjust your level of ceremony as you see fit.


At some point you’ll need to provide the estimates to someone.  What I tend to do is take photo’s of the whiteboard (to capture the design).  The assumptions, questions and so on I’ll usually jot down straight into OneNote so they are already digitized – that way I can just dump them into my write-up.  Usually the write-up will be semi-informal, possibly just an email.  You don’t have to waste time with unnecessary formality and ceremony – but the write-up should:

  • Be very clear.  Senior stakeholders / non-techs should at least be able to follow the narrative and understand the bottom line.
  • Come across as a professional piece of work, so that people won’t start questioning it’s validity based on how it is presented.

Remind people that the ROM is not a schedule, it has no sense of inter-dependencies or elapsed time, it is merely a sense of how big the work is and what the solution might look like.

Take particular care to explain and emphasize that you are providing a range not a quote. Overly zealous sales people and project managers will be tempted to take the smaller estimate and only provide this to the client.  Make sure they understand this is ill-advised. If you are hard pressed say: “the guy who wrote the article said that in his 16+ years involved in software development, every time someone took only the lower estimate things ended badly”.  If you’re from that British school of understatement, spoken with a touch of Jeeves-to-Wooster, you can say that the results will be “sub-optimal”.

You may also choose to throw all the items into a spreadsheet, with the two estimates, so that you can easily tally them up, include them in estimates back to the client, and so on.

Pros & Cons

The estimates are only as good as the experience and professional judgement of the people involved; the estimates are effectively based on nothing more than peoples prior experience, so ensure that those doing the ROM know what they are doing.  Involving juniors is good – it’s a great learning opportunity for them, but ensure they aren’t being left to fend for themselves.

As an estimation technique, it’s fairly fast and light-weight (but with a degree of rigor) so it’s useful in fluid situations.

CombiCard – a SCRUM Planning Poker app for UWP

Thought I’d mention a wee app I’ve been crafting in my spare-time: CombiCard, a scrum planning poker app.  It’s written in C# for Windows 10 using UWP (Universal Windows Platform), which means it can run on any device that uses Windows 10 as it’s OS.

For more info, including source code and user guide:, obtain it through the Windows Store:

So let’s quickly look at planning poker, UWP and CombiCard.

Planning poker is a way of estimating the relative size of a piece of work, via consensus.  Items are “sized” i.e. given a single overall value/score that represents their relative size to each other, in terms of effort and complexity.

I like planning poker for several reasons; for example it avoids anchoring – a form of cognitive bias where significant influence is ascribed to the first piece of information offered (the “anchor”) when making decisions.  It’s also more accurate than other forms of estimation, and it’s also a lot more fun (i.e. productive).

Windows Universal Platform (UWP) basically allows you to develop a application using a single code-base that can then run natively on any Windows 10 device (e.g. laptop and mobile). UWP will scale the UI to suit the device family it’s running on, additionally you can leverage aspects of UWP that allow you to handle specific device types and resolutions.

Which brings us to CombiCard.  It seems I’m one of the few people in my area (the planet?) to use a mobile that’s not an Android or iPhone; and whilst the Windows Store does have a few planning poker apps available the range isn’t huge, and I thought a planning poker app would be an excellent choice for my first real foray into UWP.

Why use CombiCard over another app?  It’s deliberately highly visual and customizable – as a user you can create any number of visual styles which can be applied to the cards and the main background, allowing you to mix-n-match. So if your meeting is really boring you’ll have something to do.


Here’s the colour mixer:





Available in the Microsoft AppStore:




Architectural Cheat Sheet (v3.0 – 2009)

I came up with this cheat sheet way back in 2009-ish.  At the time I was a real junior architect.

Looking at the sheet now there’s clearly areas where I have a grasp of the concept but I’m not using the correct terms, and in other areas I’d probably approach things a bit differently.

For this post I’m not going to correct everything as I think the old cheat sheet still offers an interesting point of view.  So if I was to redo this now, how would it be different?  Who knows – sounds like I just got a new to-do item.


Basic questions that apply to everything

Who – What – Where – When – How – Why

Time based aspects

  • Is this the first time (new) or a repeat (existing)?
  • How likely is reuse: how soon, how often, by whom?

Structure vs Behavior

(That’s it, simple as that.)


Performance Influence Matrix

Factors relevant to performance.

Users Transactions (Handled by a package) Data-Flow (between packages)
Frequency (peaks, etc)
Volumes (totals, etc)
  1. Throughput – Transactions per unit of time.
  2. Performance – Elapsed time per transaction.
  3. Latency – Wait time for a response.
  4. Capacity – Number of users / entities the system can support for a given configuration at a fixed level of performance.
  5. Scaleability – Ability to increase capacity.
  6. Reliability – Length of time a system can operate without failure.
  7. Response Time – Performance as perceived by a human.

Security Matrix

Factors relevant to security

  1. Protection of data, both at rest and in-flight
  2. Protection of resources (misuse of services / functionality)
  3. Protection of systems (DOS, Out-of-band attacks, etc)
  4. Boundary defense vs in-depth (e.g. encryption)
  5. Authentication
  6. Authorization
  7. How will Authentication & Authorization be enforced, be managed?

Logical Layers (not including hardware)

  1. User Interface
  2. Application Layer (Service Layer or Controller Layer)
  3. Domain Layer (Business Layer, Business logic Layer or Model Layer)
  4. Infrastructure Layer (data access, logging, network access, security, email, file system, and so on)


  1. Design, Prototyping
  2. Development / Refactoring
  3. Testing (suitability, integration, performance, …)
  4. Deployment / Use

Management Matrix: Who owns and controls what?

The point here is to take the concepts of Stewardship and Custodianship and apply it to the different parts of the stack.

Ownership Control
The process (that the system implements)
The hardware
Platform (OS)
The system(s) (software / services)
The data

Business / Project Management

  • What are the Critical Success Factors?
  • Is there a common terminology across all involved parties?


Information Architecture

  1. Organization / Structure
  2. Labeling
  3. Navigation, Browsing
  4. Searching


Information Lifecycle

  • Create, Read, Update, Delete



  • Atomic, Consistent, Isolated, Durable


Architecture -> Capabilities -> Features

  • Execution qualities: such as security and usability, are observable at run time.
  • Evolution qualities: such as testability, maintainability, extensibility and scalability, are embodied in the static structure of the software system.


Some System Quality Attributes

  1. Accuracy: Indicates proximity to the true value (how close are you).
  2. Precision: The repeat-ability or reproduce-ability of the measurement (consistency within certain bounds).
  3. Modifiability: Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
  4. Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
  5. Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  6. Performance
    1. See “Performance Influence Matrix”
    2. Expected transaction & response times (average, worst case)
      • response times
      • transaction rates
      • throughput
  7. Availability
    1. Service Level Agreements
    2. Percentage of time available and/or hours of availability
    3. Expected recovery time
  8. Compatibility
    1. Backwards compatibility.
    2. Dependencies – do they change between versions.
  9. Extensibility: New capabilities can be added to the software without major changes to the underlying architecture.
  10. Modularity: Well defined components, separation of concerns.
  11. Maintainability: the ease with which a software product can be modified in order to:
    1. Correct defects
    2. Meet new requirements
    3. Make future maintenance easier
    4. Cope with a changed environment


Operating constraints

  • System resources (storage, memory)
  • People (hours of business, location)
  • Software (dependencies, minimum requirements)



  • Physical location
  • Political location (e.g. hosted internally or externally)
  • Ease of access (maintenance) vs. Security
  • Dependencies
  • Communication between locations/servers/etc (how, management matrix, etc)


Levels of Granularity

[Macro >] Systems / Components / Classes [< Micro]


Some possible Views & Perspectives

  1. Logical (typically coarse grained view)
  2. Functional (fine grained logical view)
  3. Deployment / Physical
  4. Business Process (and specific roles within that)
  5. Specific scenarios (both business and technical)
  6. Application (Class / Module / Package / Component / Service)
  7. Run-time (Concurrency / processes / threading)
  8. The User.
  9. Various stakeholders
  10. Data
  11. Security / Attack Surface
  12. Public / private, internal / external


Other things to consider

  1. Alignment with current and future technology stacks, industry trends
  2. User Interfaces
  3. Backend Interfaces / integration
  4. Context
  5. Responsibilities (both within the systems, and teams delivering them)
  6. Design Patterns
  7. Platform(s)
  8. Appropriate Granularity
  9. Supportability
  10. Maintainability (evolvement – extension – refactoring)
  11. Dependencies (on other parties, systems, services, standards)
  12. Interoperability adherence to standards, or: is achieved when the coherent, electronic exchange of information and services between systems takes place.
  13. Portability
  14. Resilience / Robustness: the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance.
  15. Resource constraints (processor speed, memory, disk space, network bandwidth etc.)
  16. Scalability (horizontal, vertical / out, up)
  17. Security
  18. Usability by target user community

Availability In Real Terms

[Re-posting content I originally published in 2009! Some how it had gotten lost – it now returns]

I though it’d be worth defining ‘availability’ in real terms – terms that any non-technical person could understand.  After all when someone says %99.9 – exactly what do they mean?  As always – how you ask the question is just as important as the answer.

Availability in Real terms

Availability in Real terms - maintenance window

PDF: Availability In Real Terms

WSAF Survey 2015 – Results

A while back we put a survey questionnaire to the architect community via and LinkedIn, which included questions such as:

  1. How long have you been in IT?
  2. How long have you been an architect?
  3. What Title best describes you as an architect?
  4. What did you do before you became an architect?
  5. Career progression: what role do you aspire to move into next?
  6. What is your biggest challenge as an architect?
  7. Do you feel you are effective as an architect?
    • Why? Please tell us what you feel makes you effective / ineffective as an architect
  8. What advice would you give to new / aspiring architects?

Despite having 680 WSAF members on LinkedIn, and 142 on we only managed 10 responses.

In some ways it was far less than we were hoping for – given our numbers on paper.  I do acknowledge that as organizers of the group, the WSAF isn’t perhaps as active as we’d like to be, however, it might also be a reflection of  the local kiwi architect culture, and symptomatic of the channels we currently use to reach you all.  Community engagement is an area we are conscious of and something we’d like to increase in future.

The Results

Whilst the low response rate may render the quantitative results less than statistically sound they did provide some interesting insights.  Some of the questions were more qualitative provided some quite thought-provoking comments.

You can download the raw results here:!4940&authkey=!AJstOf7P6LaCOZU&ithint=file%2cxlsx

[The results (xlsx) and images posted here are hosted on Microsoft OneDrive, let me know if you are having trouble accessing them.]

Who Responded?

In terms of roles most of you were, unsurprisingly, Solution Architects or Enterprise Solution Architects:


How Long?

  • How long have you been in IT?
  • How long have you been an architect?

As you can see, most of the respondents have been in IT for 10 years or more, in fact mostly for 16 or more; but a relatively even spread of years experience as an “architect”:

How Long

Career Progression

We asked what people had done before they became an architect and what they think they’d like to do next.  As you can see, software development is a common starting point (I notice we didn’t get any Infrastructure Architects responding) with Enterprise Architecture looking like the most popular next destination:

Career Path 2


I’m extremely pleased no-one felt categorically ineffective, but then there wasn’t exactly an over abundance of confidence either: half of our respondents answered “yes” whilst the others said (typically for architects) “It depends”:


Selected Comments

In closing, here’s a selection of comments we received to the more open-ended questions:

What is your biggest challenge as an architect?

“Inter-Personal communication, especially when doing Enterprise level work dealing with application level architects.  Some cannot see the forest from the trees and want to re-litigate the “what” (strategy aspects) instead of focusing on the “how” (how to make it work to achieve the what outcomes).”

“Understanding the role within the political landscape, and being able to effectively convey this role to business and it people who don’t understand/value the role of an Architect.”

What do you feel makes you effective / ineffective as an architect?

“I think of myself effective when I align architecture with the business strategy and maturity. Not the best architecture, but the best fit architecture for an organisation at their particular maturity, budget and strategy level make me an effective architect.”

“Effective with a balance of inter-personal skills and technical abilities.”

What advice would you give to new / aspiring architects?

“Focus on the outcomes and what constitute success for the business, not so much the process of architecture (standards, practices, the next best thing), but more the product of architecture (alignment, value, outcomes).”

“Use Rozanski and Woods.”

WSAF – Un-Conference 2014 in the works

Just to let you know we (the WSAF) are planning on holding a bar camp / un-conference around late October / early November 2014.

Stay tuned for more information – we’re just trying to confirm the venue and dates.


You can find the WSAF (Wellington Solution Architects Forum) on LinkedIn here:

How Not to Screw Up an RFP Response

Originaly posted by AdrianK, 26-Jan-2010 at:

Vendors typically have to expend a huge amount of effort when responding to an RFP.  This article looks at how they can help themselves (and thus the client), so that the effort isn’t wasted.  The short answer is that whist RFP respondents typically focus on the solution they are offering, the real key is to take the human factors of the reviewers into consideration.

In my role as a Solution Architect (or perhaps just by being one of few resident development skilled geeks) I contribute to the RFP process – on the client side.  I’ve also done a wee bit on the vendor side too.

Having done a string of RFP reviews in recent times I feel compelled to provide some feedback to those of you out there who submit RFP responses; and whilst most of you are doing well there are others who (with all due respect) desperately need some help.

[A bit of context – this feedback is based on experiences within the New Zealand public sector.  I can’t vouch for other countries but I’m sure a lot of these points are transferable].

Before I lead us through the vast litany of unfortunately very common mistakes, let me give you some insights into the life of a RFP reviewer so that you can understand the context in things happen.

RFP’s are generally structured into sections with specific statements and questions within each; for the review, reviewers will be given a pre-defined score sheet from the contracts team (who usually oversee issuing of the RFP), and it’s no mistake that the score sheet utterly reflects the RFP.

Some score sheets expect the reviewer to individually score each answer and question pair; others expect a single score per section of questions. 

When I’m reviewing responses that require score by section, I generally work through each section in turn for all responses, in other words I work by section not by response.  For example, for a recent RFP review I was reviewing a stack of hardcopy responses:

  1. I usually start with a very brief flick-through of all the responses to get a feel for what’s coming.  The score sheets are usually in Excel all setup with the respondents entered and formulas ready to aggregate results on a separate worksheet (which I avoid looking at until the end of the review).  I stack the responses in the same order they are in score sheet.
  2. I’ll review the RFP itself again, as well as the question and answer sets that have been created – and I’ll have full print-outs of each at hand.
  3. I’ll then start the review proper, starting with the first appropriate section and the first response, then moving on to the next response.
  4. Once I’ve scored all responses for the current section I’ll move on to the next.
  5. If a section to be reviewed is large or covers multiple topics (they aren’t always as cleanly segregated as you might want) I’ll setup a more granular sub-score sheet of my own somewhere; in this case I might start reviewing responses per individual question, but not always.

Additional notes for each score are also entered; these are pretty essential for the final group review.  As you might know the RFP’s will be reviewed by a group of people who will then come together to thrash out a result (or a short list).  In a recent case my review took a full week (including normal day to day interruptions) thus the notes are essential.

Once the reviewers have completed their individual reviews (and scoring) they all get together for a formal review and scoring session where the final grading is done – this is the bit that counts.

The crucial point is that reviewing RFP’s is long and tiring work, particularly if there are a lot of responses, and it’s harder with responses that are of a poor quality.  Thus one of the keys to a good result is to take the human factors of the reviewers into consideration – make your response a pleasure for them to score.  So, how do you actually do that…


If you want best “bang for buck” this is the mistake you can’t afford to make: as mentioned above RFP’s and there score sheets stick to the same structure – deviating from that structure in your response is asking for a serious amount of pain and may well land you in the bottom %60 of scoring.

When you have to review and score a dozen odd responses you don’t have time to hold peoples hands – if the your response clearly follows the RFP structure the reviewers won’t have to think [1] in order to find the information to review, and they’ll thank you for it.

Use section names and paragraph / question numbers from the RFP to label the content in your response, and include this in the table of content if appropriate: make sure it’s really easy to scan, use decent indenting, bolding and other presentation techniques to make it so – but don’t go overboard. 

With most RFP responses, at least some of the respondents will do just that; this consistency makes it easier for reviewers to work with those responses and the more that do this the more they will all benefit from the consistency; correspondingly, failing to do so will put your response comparatively on the back-foot.  This is particularly true the more responses there are.

Next on the priority list is a decent Table of Contents (ToC), and please, please, please don’t forget page numbers.

What you want is a nice, clear, easy to read ToC which matches the RFP structure, with page numbers so I can jump straight there.  “Hand-Over”?  Oh look its on page 28.  “Security Testing”?  Page 13, bingo.

RFP’s that do none of this are so awful to review it’s not funny, and it takes little imagination to guess how that impacts on scoring, after all you can’t score a response you can’t find.

I’ve seen everything in between: responses with no ToC, ToC but no page numbers (bizarre) and page numbers but not ToC (near pointless).  The sad truth is that whilst the reviewer should be scoring you on you content, you’ll get scored on your delivery instead – if it’s poor. 

This brings up an interesting point, in that (for the reviewer) there’s often a fine line between scoring the response and scoring the way it’s delivered, and the division between the two can get quite murky at times.

Finally, RFP reviews always include a section for presentation and delivery; these should be easy points to win if you follow some of the advice above.

Content Quality

By this I don’t mean that you offer a database that is redder than everyone else (a red database is fastest, yes?); what I mean is that your response must answer the questions that have actually been asked.  You might think this was obvious, however, I regret to inform you that the obvious is obviously not that obvious.

Failing to actually answer the question is at least as dangerous as ignoring the RFP’s structure.  First tip: actually read the question.  Read it again and make sure you understand it.  Count to ten before you start writing.  Discuss it with a peer.

It’s tempting to respond to the “training” section of questions with your standard training blurb – don’t rely on this.  Make sure you understand the specifics of what is being asked and directly answer it – make it as easy as possible for those poor tired reviewers to give you full marks.

Responses that (reading between the lines) suggest the respondent is capable – but which don’t directly answer the exact stated question put the reviewers in a tricky position. 

If in doubt answer the question directly (‘what they asked – not what they meant”, as strange as it might sometimes appear) and then additionally provide a ‘second’ answer that answers “what they meant not what they asked”.

In short: make sure you directly and specifically answer all the mandatory questions in the RFP.  Reviewers generally mark a score as set-out in a predetermined score card (most likely defined by the internal contracts team); one of these options will cover responses that fail to answer questions specifically.  Often questions can be lumped together into section and a score is given for the section as a whole – if you don’t answer all the mandatory questions you risk being thrown into the ‘failed to provide a response’ category even if you did answer some of the questions.

Consider very carefully when asked to describe your approach to completing a specific deliverable; is the RFP trying to elicit the steps you go through or your thinking behind those steps?  It is – trust me.  Knowing what your process is can be illuminating (but not always in the right way) where-as getting an understanding of why you do it that way is often more helpful – it shows that you can justify your approach or might suggest that (due to your understanding) you can compensate when variations occur.

“All software we produce under goes our comprehensive range of time-proven of software testing techniques” is not going to score you anything.

“All software component testing is automated using N-Unit with code coverage of at least %80 by the end of every sprint.”  Is much better – I know the tools you use, it looks like you know what you’re talking about (code coverage) and your testing is integrated with your development methodology (don’t tell me you’re “agile” elsewhere in the response and then fail to mention relevant agile practices where appropriate).

Content Quantity

Reviewers will be looking to get the review done as fast as possible – be as succinct as possible – both in volume of text and presentation.  The average reviewer may not be too interested in a whole page executive summary

(although this kind of thing may be useful to others?).  Also, the bigger the document is the harder it will be for reviewers to find information if it’s not blatantly obvious from the table of contents.

The balance between too much info and too little can be a very delicate one, and it’s easy to get wrong.  One approach that might work for you is to provide some level of detail (to try and expose your depth of knowledge) but not for the whole breadth of the issue

Pick you targets; make sure you understand the RFP and your relative strengths and weaknesses, what responses are you giving elsewhere?  Some questions will lend themselves to a longer answer better than others, and for others a shorter answer.

If the RFP simply states that you need to confirm acceptance or acknowledge something then do so (assuming you accept, of course); something like “We confirm acceptance of this requirement” should do the trick.  Evaluate the question – don’t feel you need to give additional info if it’s not necessary. 

If you add additional information please make sure you still formally state acceptance as a clear acceptance is the fastest way to full marks. 

Starting with the acceptance and then providing additional info is probably best.  One advantage of sticking to the acceptance statement only is that it means you can add more content elsewhere; save yourself for where it’s worth going the extra distance, so that the overall response isn’t bloated.

Name drop – Mentioning the names of specific processes and technologies can be a very useful way of conveying a sense of depth without going into detail, for example: when questioned about security testing name-dropping specific threats demonstrates a knowledge of the domain – “… protection against SQL Injection, XSS, and Drive-by attacks…” makes it sound like you know what some of the potential and specific threats are, where-as simply saying you’ll defend against malware is very vague.  Of course anyone can name-drop things they don’t actually know anything about, but the rest of their answer (and the way it is written) should give an indication as to the overall authenticity of their knowledge (as will the response overall).

Name-dropping is also useful in that anyone scanning a page of text might recognise words which catch their interest – and so lead them to actually read your response more closely.  Conversely – a lack of ‘buzz-words’ might imply that you’re merely waffling.

Conversely, be careful not to rely on name-dropping alone; there are definitely circumstances where it’s worth putting a small degree of appropriate fluff around things; and also along these lines it’s a good idea to provide the full name rather than the acronym only.  For example, when listing relative experience:

  • Wrong:  SOA
  • Good:   Service Orientated Architecture (SOA), 5 years experience.

Don’t wax lyrical about the subject if it’s not directly answering the question, for example: don’t discuss the advantages of standards compliance if the actual question is to simply state how you actually ensure the standards are met.


Have you ever been guilty of judging a book by its cover?  Presentation counts – and done right it’s easy an ‘easy’ way to earn points.

There are a number of points to this: the obvious visual and aesthetic aspects and (the less flashy but just as important) usability aspects like layout and wording.

An optional but useful technique is to prefix your individual responses with the actual question from the RFP, this leaves the reviewer in no doubt they have found the right content.  A clearly headed and structure response should negate the need for this – so it does depend on how you want to present your response.  It can also help whoever is writing the response to stay focused on target. 

If you have supplementary information in other parts of the document mention it clearly at the end of the ‘formal’ part of the response to a specific question.  Supplementary info is good but may not always be read in full by all reviewers:

  1. Reviewers will focus on the formal responses first and they may not review supplementary content particularly if they are under time pressures, tired or feel overwhelmed.
  2. If the reviewer thinks they have formed a sufficient opinion based on the ‘formal’ answer to a question they are unlikely go looking for additional info.

Including additional sections of information is fine – just make sure it doesn’t get in the way; reviewers hate having to wade through a big thick document just to find the information they need.

Never attach core information separately to the response (“sample widgets attached as jpegs”), if it’s worth including in the response please embed it in the actual response, and ensure it looks crisp when printed / photocopied in black and white (because not everyone will print in colour).

One approach is to include a “lesser” (but usable/readable) example in the RFP response document and a big flash high-res copy as an attachment – if the lesser example wets the reviewers appetite they’ll be more likely to go to the trouble to look at the separate attachments.

Think about who will be reviewing the responses: it will be a range of people with various skills and knowledge; what they will all have in common is (probably) a lack of time, tiredness and a lot of responses to go through – make it easy for them.

A lot of companies have pre-defined templates for making pitches, and some of these appear to be used for RFP responses; by all means use these as checklists or something to spark though on the response – but don’t use the template for the response: it probably won’t relate to the structure of the RFP, and will attract the pitfalls mentioned above.  In addition, a response whose structure bears little resemblance to the RFP makes it look like you haven’t even read the RFP – a sure-fire way to get the lowest score (or risk getting thrown out altogether).

Website focused RFPs’ will typically have requirements around the aesthetic needs of the website; don’t provide text only answers – visuals are a must.  Be pedantic over how these are displayed – they must be high quality (Nothing beats a quality full colour reproduction of a nice visual).  Think about how the RFP is going to be actually delivered (usually a combination of both hard and soft copies).

When binding the response make sure it’s easy to turn the pages and that all the content on the page is clearly visible.  Responses that sit fully open on any given page are a blessing – ones that refuse to sit still without folding over are painful.  Ring binding is good, avoid staples and paper clips.

At the end of the day – if the RFP calls for a solution with any sort of aesthetics you don’t want a poorly presented response; if your response looks mediocre it won’t give the impression you can deliver a ‘killer’ design.

Thinking Ahead

RFP responses are usually reviewed by a group of people – usually selected to provide a range of stakeholders and expertise.  You’ll have business focused reviewers (perhaps end users of the system) as well as reviewers who are there mainly for the technical aspects.  These different audiences may or may not have the same degree of sway within specific areas of the review. 

One thing to consider (for example) is the kind of language used to answer a certain question, for example: answers that require a technical response will probably require a different language style than answers that deal with more empirical subjects like visual design and user engagement.  Think about the kinds of people who will be reviewing your response – and not just the response as a whole but also those that might focus on a specific area (technology, business, project management, and so on). 

Get your geeks to write the technical content, chances are the reviewers will rely on the geek reviewer to help guide them during the final review session where the final scores are thrashed out.  The same applies to other sections of the response – get the most relevant person (like the appropriate Subject Matter Expert (SME)) to write the content for a given area; get others to review and critque their work but becareful not to stamp all over their style and approach too much if it’s likely to appeal to the corresponding SME on the clients side.

Staff / Resourcing / People

One of the sections you’ll find in a typical RFP is one that requires you to provide information on the staff who’ll be working on the project, and you’ll usually be asked to explicitly state staff members by name against specific roles.  This will be mandatory – so make sure you do it.

Make sure you answer the question – kind of obvious; don’t just rattle off the standard blurb (unless it’s fit for purpose) – it’s easy to slip into making the mistake of covering someone’s past history even if it’s not directly applicable.  Make sure you directly and clearly answer the specifics of the question before adding details about what you do in your spare time.

Typically you’ll be asked to provide relevant details as to the experience of these people, perhaps in the form of a one page CV, there are many pitfalls here to be wary of – including all the baggage that usually goes with good CV writing, but there are several simple things you must do to avoid a bad review:

  1. At the very least: state the number of years experience in the relative field.  Stating the number of years the person has worked for your company is pretty much irrelevant – say that if you want to, but only in addition to their total relevant experience.
  2. Stating relevant skills, projects, technologies and so on is good but not enough on its own (see the ‘name dropping’ section, above).  Please don’t provide three pages of waffle and not state the total number of years of relevant experience.
  3. Provide all Staff CV’s / Bio’s in the same format.
  4. Pictures aren’t mandatory but are generally a good idea – people like seeing people.  Make sure the photo quality and reproduction are excellent otherwise the value of having the photos will be diminished or may backfire completely.

RFP requests are typically after a well rounded solution (for example, if its a website there will probably be business, aesthetic, architectural, development and testing aspects that need addressing), bear this in mind when providing staff bio’s.  I’ve reviewed RFP’s that needed a breadth of skill, and seen responses that listed a bunch of developers or designers and little else. 

Don’t be afraid of out-sourcing.  As a general rule I’ll give more points to a response that out-sources security testing to a specialist [2] firm rather than one that does it in-house, although this can depend on the size and skill of the vendor behind the response.  That’s my personal position, and not everyone has the same views as me.

I guess there’s the potential for that to backfire if the owner of the RFP has some pre-conceived idea that they want a single vendor to deal with.  If you’re a small firm then I’d say you’re better off taking the out-scouring route, and you can always have them working for you as a sub-contractor – so there’s still only one point of contact (and invoice) for the project owner to worry about.  Just make sure you’re clear in your response.

In Conclusion

Writing a good RFP response is learnt skill and it’s evident when the response is coming in from someone who has done it before, but you have to start somewhere.  It’ll be your team that does the actual work if you win – so you’ll stand the best chance of winning if the team contributes to the response.  Allow yourself plenty of time, check the basics – and go get ‘em!


Some rights reserved.