Estimating the Estimation

Estimating the amount of time documenting a good business analysis/solution design document will take is never an exact science – often the time required for a good document will take to produce only comes out once you have already started running the Analysis Workshops or the document itself. However from a commercial perspective, the time agreed with the client will usually have been fixed prior to the beginning of the workshops themselves.

From experience, I see this Analysis phase as the most key phase for any CRM Project as a good understanding of the processes involved, business aims and user experience should lead to a good solution design which can save dozens if not hundreds of days in development and be a massive boon to user adoption.

I have seen various methods of calculating the time required for documenting a good solution design document (and a bad few based on the ‘how much can the client afford’ method!) with mixed results based on the following metrics:

Workshop Time Different clients will generally have different amounts of availability for workshops, leading to some workshops having a lot of ‘fat’ time to go over a process in detail whilst others must be managed carefully to investigate the required points in the time available. Althrough I think Workshop Time is the best metric for measuring how long a good design document should take, this should probably not be taken as the sole metric.
Number of Users

The number of end-users for a CRM Solution is not a berometer of how complex the solution is required to be. I think number of users plays a part in determining how professional and complete a document needs to be (as higher number of users will generally mean a higher number of readers) but otherwise is not a very useful metric in estimating documentation time.
Previous Work If a detailed Scoping document is available (ideally produced by the same Consultant or Team) then obviously this should be taken into account – and usually a good scoping study should give a clear estimate for the next analysis phase in the project.
Previous Systems Involved This is a good metric of likely complexity of the solution design and a good method of pushing away requirements to integrate or replace systems that may be a ‘nice-to-have’ requirement for the CRM Solution. Generally the more systems the CRM Solution is replacing or integrating with, then the more documentation time should be allowed to produce a good solution design.

In my experience, boiling these metrics down to give a pre-workshop estimate can go as follows:

1 day for the base Document
Time to produce the business aims, solution overview, clean up the requirements documented in the workshops, effort estimate and other key sections of the document. Always think that a good day is required to baseline the document and ensure that the required level of professionism is present.

1 x day per business process or process area identified
Breaking a Solution Design document down tends to result in a number of Business Processes or Process Areas that will each form a key section of the document. This will typically be one section per one workshop session to again use the metric of the number of workshops involved, but not always.

1 day for a Solution Data Dictionary
Data Dictionaries are a mixed blessing for CRM Projects – on the plus side, seeing a full list of fields and descriptions is very useful for the Document Reviewers to pick up on missing or excess fields. On the negative side, data dictionaries tend to be long and can over-complicate the narrative of a good document (and if relegated to an appendix, often run the risk of never being read for the same reason!) as well as being time-consuming to produce. I am in favour of always producing a Data Dictionary, but in some occasions a good diagram summarising the Entities, Relationships alongside prototype screens can suffice.

N x number of additional solution design days based on the business complexity
The key here being business complexity as opposed to solution complexity (as thinking pre-workshop, we have no idea of the solution complexity as yet), to take the number of users (50 or 500?) and the existing systems that we are looking to replace to produce a small number of days to ensure the solution design takes these less-quantifiable factors into account. So for a small project (say 40 users and 1 or 2 legacy systems) this might mean no additional days beyond what has already been identified from the workshops involved, however for a larger project (200 users, 2 systems to be replaced, 1 system to be integrated with and 1 other system that plays a part in the wider business processes) this may add an extra 1 or 2 days to the documentation time.

1/2 day for peer review of the document and estimates
Always key to have a second opinion on any document prior to release.

1/2 day for playing back the solution design to client stakeholders
Not strictly part of the documentation as this would come after the document has been produced and released to the client – however I count this as an absolutely crucial part of presenting the solution design back to the stakeholders who are involved with the project and the attendees from the original workshops.

So for say a small project with 3 core businesses, we may have:

3 x days of Workshops for 3 different business processes.
1 x day to document the project aims and core solution design.
3 x days of time to document the processes involved in the Workshops.
1 x day to document the Data Dictionary.
1 x day for peer review and playback presentation.

For a larger project, we may have a more detailed elaboration:

5 x days of intensive Workshops covering a wide range of 10 business processes.
1 x day to document the project aims and core solution design.
10 x days of time to document the processes involved in the Workshops.
1 x day to document the Data Dictionary.
3 x days for the additional solution design required to incorporate SharePoint integration and replacing legacy systems.
1 x day for peer review and playback presentation.

(the estimates here not including subsequent Data Migration, Integration and Technical detailed designs which we would expect to be identified during this analysis and estimated as effort required for the next phase of the project.)

Having run these analysis phases for a number of years across various MSCRM Projects so am drawing on more personal experience than anything else – would be interesting to see how other disciples outside CRM or other consultant’s experiences on getting a good estimate for the initial Analysis phase come about.

This entry was posted in Analysis/Design Documents, Consultancy, Documentation. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s