The Scope Document is created to list the scope of work that will be completed at the end of a specified time frame. It can be utilized in any development methodology, but is most prominent in the Waterfall or Spiral methodologies.
The document is extremely important for companies that operate on a fixed cost business model, because it serves as a written reference for the functionality that will be delivered in the final solution. Once completed, the document is usually given to the client, along with a presentation and Q/A session. The client then has a specified time frame for review, after which they can request any changes. Once both the company and the client agree to the work specified, the document is signed and the work can begin. This type of model allows for the client to know exactly what to expect of the final functionality of the solution while allowing the company to plan resources and base prices on the estimates of work.
As development managers the task of creating much of the scope document will fall to you. It is very important to follow some basic overall guidelines when creating the scope document.
1. The scope document will be used as the official description of functionality for both the client and for the time estimates used to price the project. Because of this, it is very important that the document list a high level overview of all the main functionality that will be included in the solution. It is a good idea to include as much visual representation of functionality as possible within this document to help the client understand exactly what they are buying.
2. The language used should be as non-technical as possible. The purpose of this document is not to identify the technical means of providing the functionality, but to define the functionality in such a way that the client can understand.
3. The document should include a list of "Assumptions". The assumptions can include technical details to a certain level, such as the hosting environment (when applicable), the development platform, and the target client (i.e. Windows OS, target browsers, etc).
Saturday, August 4, 2007
Wednesday, August 1, 2007
Development Methodologies
Development Methodologies are known to draw strong opinions from developers and managers a like. Many things can come into play when making the decision as to what methodology your team should employ. Some of these decision factors include the core strategy of the company, skill level of the team developers, and central goal of the solution being developed.
1. Waterfall
The waterfall methodology has been around for a long time. It basically involves creating a detailed scope of work, getting the appropriate people to sign off on that scope of work, and then building the solution. The scope can not change and the product is finalized after the completion, unless an additional phase is recquisitioned.
I once worked at a web dev. shop that made its living with this methodology. Most of the projects were fixed price solutions for external customers who wanted to make sure they got their functionality for the guestimated price. The solutions were created in scheduled time frames and once a scope of work was defined and accepted by the client it was rarely changed. Any changes desired by the client would usually result in a phase II, III, or IV of the project.
2. Spiral
The spiral methodology involves taking a small amount of core requirements for a solution and going through the software development life cycle (SDLC) to implement those core requirements. The development team has every intention of going back through to implement additional requirements as they become apparent. This is currently the most used methodology because it allows for quick results, some agility in the requirements, and a team made up of developers at various skill levels. That being said, it is also prone to bugs and usually lacks up-to-date documentation.
3. Agile Development
The Agile Develoment methodology is the newest of the three methodologies discussed here. There are several variations of the methodology, but all share the following core concepts as stated in the Manifesto for Agile Software Development (http://www.agilemanifesto.org/)
- Individuals and iteractions over processes and tools
- Working software rather than comprehensive documentation
- customer collaboration over contract negotiations
- Responding to change over following a plan
This basically allows the development team to be self organized, have less emphasis on documentation (which is usually not kept up to date anyway), have direct access to customers (so that the projects get done exactly as the customer expects), and welcome changing requirements.
This can be a very good approach for teams consisting of self-starting, expert developers that are working on a select number of products for various internal and external customers. The methodology may not be the best for teams that require a large amount of documentation, have a business model that requires fixed prices, or have more junior to mid level developers than experts.
--------------------------------
I have worked at various companies which have put into practice each of these methodologies in some form or another. Each has its advantages and weaknesses and I have come to the conclusion that the best methodology is likely a mixture of three. My next blog will dive into one of the key features of the Waterfall method, the Scope Document.
1. Waterfall
The waterfall methodology has been around for a long time. It basically involves creating a detailed scope of work, getting the appropriate people to sign off on that scope of work, and then building the solution. The scope can not change and the product is finalized after the completion, unless an additional phase is recquisitioned.
I once worked at a web dev. shop that made its living with this methodology. Most of the projects were fixed price solutions for external customers who wanted to make sure they got their functionality for the guestimated price. The solutions were created in scheduled time frames and once a scope of work was defined and accepted by the client it was rarely changed. Any changes desired by the client would usually result in a phase II, III, or IV of the project.
2. Spiral
The spiral methodology involves taking a small amount of core requirements for a solution and going through the software development life cycle (SDLC) to implement those core requirements. The development team has every intention of going back through to implement additional requirements as they become apparent. This is currently the most used methodology because it allows for quick results, some agility in the requirements, and a team made up of developers at various skill levels. That being said, it is also prone to bugs and usually lacks up-to-date documentation.
3. Agile Development
The Agile Develoment methodology is the newest of the three methodologies discussed here. There are several variations of the methodology, but all share the following core concepts as stated in the Manifesto for Agile Software Development (http://www.agilemanifesto.org/)
- Individuals and iteractions over processes and tools
- Working software rather than comprehensive documentation
- customer collaboration over contract negotiations
- Responding to change over following a plan
This basically allows the development team to be self organized, have less emphasis on documentation (which is usually not kept up to date anyway), have direct access to customers (so that the projects get done exactly as the customer expects), and welcome changing requirements.
This can be a very good approach for teams consisting of self-starting, expert developers that are working on a select number of products for various internal and external customers. The methodology may not be the best for teams that require a large amount of documentation, have a business model that requires fixed prices, or have more junior to mid level developers than experts.
--------------------------------
I have worked at various companies which have put into practice each of these methodologies in some form or another. Each has its advantages and weaknesses and I have come to the conclusion that the best methodology is likely a mixture of three. My next blog will dive into one of the key features of the Waterfall method, the Scope Document.
Subscribe to:
Posts (Atom)