Whenever I am beginning a new software development project the clients first questions are: “what is it going to take?” and “how much is it going to cost?”. These are two very big questions and normally take a lot of system analysis work to derive. This can be done in various ways and everyone has there own preference. I normally put together a project scope document that lays out many of the fundamental parts of the development effort.
So far my largest project scope document has been 14 pages, but I have also done small ones that fit nicely into emails. The length of the document is largely dependent on the size and complexity of the system you are implementing. It usually takes anywhere from 3 hours to 2 days to gather the required information and I don’t charge anything for the analysis. This is kind of like requirements gather, but not as detailed. I usually jot down a few key requirements that will largely impact the scope.
When doing this analysis you need to gather what kind of architecture would best fit the company. If the company has plans for rapid growth an Object Oriented or Service Orient Architecture would probably fit best. Also gather as many functional requirements to accurately estimate the development effort. Also jot down as many business entities as possible such as: sale, order, product, customer, etc. The business entities will be used as database tables and classes at implementation time. It is also curtail that a technology platform is defined in this phase of the project. This may be common sense, but a Windows Forms application would not work well on a Linux operating system. All of these factors will largely affect the scope of the project.
The main purpose of a project scope document is to ensure that the client’s view of the project is inline with the consulting company’s view of the project. Normally I go through two or three drafts with the client before I assemble the final document. The project scope document should:
1. Level set project expectations.
2. Address time and costs.
3. Provide executive management and other stakeholders with a clear understanding of what the project entails.
4. Layout risks and benefits of the new system.
Here is the general format that I use:
I. Project Charter
States the project name and purpose. This should clearly layout the description of the project and the anticipated outcome. If existing systems will be effected by the new system then list effected systems in this block. Also indicate the technology platform that has been selected for this project. Last but not least list what it is going to take to make this project successful.
II. Project Context
In this section state the problem(s) with the current system. And explain how the new system will remedy the problems.
III. Project Expectations
This section requires extensive business knowledge and involves participation from all parties that are affected by the application. List out all expectations from each department within the organization.
IV. Project Approach
List the methodologies and approaches that will be used to ensure a successful implementation. Also introduce how the standard development lifecycle will be used within each phase.
V. Project Risks/Rewards
List the risks and rewards of the project implementation here. Give each risk or reward an impact rating of high, medium, or low.
VI. Resource Needs
Define the roles that will be needed along with a brief description for each role.
VII. Cost
Layout a cost for each role, development environment, and hardwired.
VIII. Key Stakeholder Sign-off
Define the key stakeholders and get signoff.
Remember the project scope document is the gateway to the project, so make sure expectations are set up front and that there are no surprises.
*** Please do not forget to leave your comments about this article ***
TechnicalTalk » Technical Resources - Articles and Videos » Read/Post Free Articles » Estimating Project Scope
