G’day.
Today’s topic is around the Microsoft Solutions Framework (MSF) process methodology and how it relates to the process of gathering requirements and effort forecasting.
Yes, this is going to be one of those heavy blog entries.
The proper and right way to get to forecasting effort and building a solution is to determine exactly what the customer has in mind. It makes sense to define appropriately what the heck you’re supposed to be delivering. I reckon that if half of IT projects were properly estimated then we’d have probably double the number of successful projects.
A good estimation should take between 2 – 6 weeks, depending on scope, vision and so forth. Anyone who says that they can accurately scope and effort forecast a large scale project in less time is fooling themselves – even with all the great RAD tools available today, you must know as best you can what your expected deliverables are.
Any decent estimation will deliver the following:
– Draft Project Plan
– Detailed Functional Requirements
– Detailed Non-Functional Requirements
– Project Overview
– Business Objectives Document (what the project addresses, for the customer)
– Resource Schedule (how many people required, etc)
– Architectural Overview (technologies to be used)
– Costing and effort forecast
Additional beneficial, but not mandatory items:
– Draft Dev Plan (depending on time)
– Draft Test Plan (depending on time)
– Functional Process Flow Diagrams
– Wireframes
From the customer you would expect:
– One or two product managers, who speak for and represent the customer’s business
– business case documentation
During the estimation exercise you would track:
– Questions and answers (between your team and the cusatomer’s resources)
– Issue Register (track issues that come from questions or otherwise)
– Risk Register (including a regular risk review)
– Functional and Non-Functional Requirements
Now, the next blog post will contain more information on how we get from the initial engagement into the meat of a project.
