Creating a Scope Document

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).

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.

The "bulletproof" deployment

Nothing can slow down a developer's rise up the corporate hierarchy faster than a botched up deployment that negatively affects customers, clients, and the internal staff.

Though it is impossible to dress your deployment in a vest that is 100% bulletproof, there are several things that can be done to ensure that the majority of your deployments will come out unscathed.

1. The first and most important thing that can be done to make the deployment go smoothly, is to bulletproof the code. One of the practices that has made this easier is called Test Driven Development (TDD). This technique involves writing your unit tests before writing the code and using those tests to ensure that the software functionality works as intended. A friend recently brought an article to my attention that shows how much of a impact this type of development can make on a project. The results show a staggering 50% reduction in bugs when using TDD. You can view the document at
http://maximilien.org/publications/papers/2003/Maximilien+Williams03.pdf.

2. Keep a list of any problems that come up during the actual deployments or in the application after the deployments. Use that list to perform last minute testing on future deployments for both the deployment environment and the software functionality. Try to put as many of these tests into automated functionality tests (Smoke Tests) as possible.

3. Keep a check list of activities that need to be performed to prepare for deployments. Some of these activities may include creating "release" builds, updating web references of dependant software solutions, and notifying any enterprise integration partners of the upcoming release.

4. Implement a code freeze with as much time as is needed to really pound on any areas of the application that have changes, as well as do an overview of all other functionality. Have as many people as possible beat on the system and document any issues that arise. Have one person in charge of determining what issues should be fixed for the release and what issues should be logged for a fix in a future release.

5. Finally, after the deployment is finished, have several people access the application and run through various high level tests, which hit the most used functionality.

Good night and happy deploying!

Getting ahead in IT

I've known many IT professionals, throughout the years, who have wondered what it takes to move up the corporate ladder. I've contemplated this question many times and compiled the following "top 5 list" for moving up in the IT world.

1. Dress for success

Good:

The best advice that I've ever been given is to dress for the job that you wish you had. If you want to work in the mail room, then by all means continue to wear the jeans and t-shirt. If you want to be CIO, start wearing clothes that resemble what you expect a CIO to wear.

Even Better:

Plan your clothes based on your audience. I once read a sales book that said something like “wear clothes that are one step up from those that you are trying sell to". To move up the Corporate ladder you basically attempting to sell your qualities as a package. To get ahead you need to separate yourself from others while not looking like you're brown nosing.

2. Improve your communication skills

Good:

Improving your communications skills will help you in all areas of life, but especially in IT. Developers are known for poor communication skills, yet these skills are a must for those looking to rise through the ranks. To improve your skills, read books on the subjects of writing and public speaking. Also, take the occasional class. Most importantly, re-read your emails and be professional at all times.

Even Better:

Take the leap and go for that MBA. This degree will greatly improve your communication skills and will most certainly propell you upward.

3. Plan, Plan, Plan

Good:

Develop your planning skills by seeing how others go about creating action plans for similar goals. Look to anticipate questions that might come up in that Dev. meeting or conference call. Continually refine your processes and look for ways to improve.

Even better:

Decide where you want to be in 1, 5, or 10 years and make a detailed plan for getting there. Find others who are already there and figure out what path they took to get there.

4. Workout

Good:

Working out several days a week will keep you fresh and will put you a head of most of the other IT people out there. Also, let's face it, appearance does count.

Even better:

Include working out with a quality diet. A quality diet is 80% of the battle for loosing fat or gaining muscle and it plays a huge role in how quickly your mind works and continues to develop.

5. Become the expert

Good:

Finally, you have to become the expert in your field of choice. Some ways to do that are:

- Be quick to volunteer for projects (the more you have done, the more you will know)

- Read technical books on your desired subject area

- Gain a basic knowledge of other technologies that may not directly relate to your position at the moment.

- Keep an eye on new technology and be prepared to share your thoughts on that technology.

Even Better:

Start a blog about what you are learning.