Estimating Worksheet

Civic Actions recently posted their Estimating Worksheet, a tool to help generate project proposals from Request For Proposal documents (RFPs). It's awesome that they are sharing this tool with the community (under CC Attribution Share Alike 3.0 license) and I would like to thank them for doing so.

The tool is a fairly complex spreadsheet which is quite well done. The worksheet approaches proposal generation in a similar fashion to the process we follow at Raincity Studios (my day job). It's not hard to imagine that a similar method would be used at other Drupal and non-Drupal software development shops.

The worksheet provides a structure for the breakdown of the information contained in an RFP into digestible tasks. Consequently, it becomes easier to attribute values to each of the site components such as work areas (like theming or engineering) and to estimate the time required to complete the tasks. The end goal is to generate an information set that helps define the scope of the project, attribute a monetary value to it, and generate documentation to be submitted to your potential client.

The rest of this article assumes that you have a basic familiarity with proposal generation, project scoping, and production management. Furthermore, some of the terms used may sound cryptic if you haven't yet had a peek at Civic Actions' Estimating Worksheet.

Make it Two

Two aspects of this worksheet that I feel are refreshing and that have the potential to bring a clearer perspective to the process are:

1. building two concurrent proposals - one based solely on the RFP and the other that accounts for your recommendations; and,
2. the Certainty Factor.

Let's look at each of these in a bit more detail...

The Recommendation Estimate sheet allows for the generation of a totally separate proposal based on the RFP requirements and what you, as a Drupal expert, estimate would be an appropriate solution to meet the client's requirements. This contrasts from traditional RFP-bound proposal generation, as it allows for matching features with out-of-the-box Drupal functionality in order to simplify development/maintenance and potentially lower project costs.

For example: The project requires feature X that, if implemented as expressed in the RFP, would take Y hours to complete. However, you may suggest an existing contributed module which can meet most of the requirements, in a slightly different fashion, for a fraction of Y.

In RCS proposals, there is often a set of requirements that contain more than one associated cost estimate. As a result, it is difficult to come up with a “final number” that takes into consideration the potential variations in how features might be implemented.

Civic Actions' tool provides a very interesting way of viewing different sets of information (i.e. two separate proposals). This can facilitate discussion with clients about the different ways a project could be built. (Check out how the “RPB” column makes this process painless!)

Now let's have a look at the Certainty Factor...

It's always a challenge to assign a satisfying completion time estimate to a feature with a lot of unknowns (e.g. one that is poorly-defined or requires the use of cutting-edge technology). This is especially true in the context of projects with a tight budget or timeline. The spreadsheet includes the concept of Certainty Factor, which rates the level of uncertainty you might have for any given feature. A Certainty Factor for the entire project is also generated.

Having high/low estimates can provide a useful launching point for discussing with your client the features that are to be kept or dropped from the project; those that can be simplified or enhanced; and those which can be moved to subsequent phases of the project.

I can think of another potentially interesting use of the Certainty Factor. It could also be used as a good indicator of the types of projects your company wants to take on. Depending on your team's resources (availability, skills, experience, etc.) and the type of clients and constraints you would be working with (budget, timeline, client attitude, etc.), you may conclude that a project with a Certainty Factor greater than value X presents a risk factor too high for your organization. You can then pass the lead on to other Drupal agencies who would be better suited for this type of project.

Similarly, if you're interested in being on the bleeding edge and like to take risks, or if your developers need something new and exciting to work on, you may want to look at projects with a greater uncertainty factor.

Give it Some Time

One of the weaker aspects of this tool relates to project duration. Unless I missed something, the project duration is not a calculated value. I am sure it's possible to guess a time span based on the size of the project, available resources, and experience. However, I think that if intuition is combined with a more rational approach, a more precise estimation is to be expected.

In the spirit of releasing early and often, I am pleased to contribute to this tool by adding a system that can help you determine the project duration with better accuracy. Three sheets have been added to the Estimating Worksheet to create version 1.2 (?) of the document .

Here is an overview of the added functionality:

• The Resources sheet is where you enter the name of your team members. You will also be able to associate each of your resources with a weekly “production time”.
• The Assignments sheet is where you couple a Resource with an Area of Work.
• Areas are high level task groupings. Areas were available in the 1.1 version of the document. However this new Areas sheet abstracts them a step further. Areas can be defined on a project basis but they will most likely always be the same across projects. This sheet also gives you an overview of how much time each Area will take to be completed, based on available resources.

Other features are:

• Ability to determine the level of “involvement” a resource would have in a project.
• Ability to assign a resource to multiple Areas.
• Areas dependencies (single) (i.e. Area C can depend on Area B, but not on Areas A & B ).
• Areas durations inheritance (i.e. Area C start date depends on Area B , which depends on Area C).
• Generation of low, high and average project duration.
• Anticipated start date and Estimated end date.

Of course, there are shortcomings - this is, after all, a spreadsheet... Here are a few I can think of: multiple dependencies, exceptions to schedules (e.g. for vacations, sick days, etc.) and ability to view resource allocation across multiple projects. Regardless, I feel this constitutes an overall improvement on the 1.1 version. I would be happy to continue to collaborate in making this tool better.

Please read the notes embedded in the document. Thanks for reading!