Archive for April, 2009

Requirements – What Users Want

Monday, April 20th, 2009

The first step in any project is finding out what the users actually want.

Requirements management is the process of documenting, testing and analysing the statement of stakeholder wants and needs.
Requirements are the statement of need that a project has to satisfy, theystate the problem to be solved and define the scope of the solution.

However users are not always able to communicate what they want clearly, and the key is to gather the requirements while allowing flexibility for the chosen solution.

Requirements gathering is a creative process and involves careful listening, brainstorming and elicitation. A good requirement is:

  • Clearly defined
  • Testable
  • Agreed by all stakeholders

There are two types of requirements:

Functional Requirements

These are the statement of capabilities, they express what the intended product must do in terms of behaviour. They are binary in nature, they are either present or absent.

Non Functional Requirements

These are the quality attributes of the functional attributes, they are often called soft requirements. They include things such as speed, efficiency and longevity. They should still be testable and clearly defined. A product may fulfill its use but still not be usable to clients, so non functional requirements address this space.

Tomorrow I will be looking at the process of good requirements gathering.

Tags:
Posted in General | No Comments »

Change Request Form

Friday, April 10th, 2009

Following on from the post yesterday on change management, I thought I would write a quick list of the elements that should go on a change request form.

  • Serial number of id – to identify the change
  • Name of originator and department
  • Brief description of the change
  • Reason for the request
  • Estimated effort for project time and cost
  • Authorisation or rejection decision and signature
  • Reason if rejected

Change request forms should not be used unless you are working on a large project, that impliments design freeze. However by tailoring this form it is possible to get people to think before they request a change.

A more usuable form may include:

  • Name of originator
  • Description of change
  • How it materially affects the success of the project
  • Why the change cannot wait until phase 2
  • The cost of the change in time and resource
  • Reason for accepting or rejecting the change

Tags: ,
Posted in General | No Comments »

How To Manage Project Changes?

Thursday, April 9th, 2009

Changes to a project can be one of the big issues when managing a project, they can affect your planning, cause confusion and serious delays to projects. Changes made at the beginning of a project usually have less of an impact than when most of the design is complete.

There needs to be a system for people within the team, stakeholders or anyone else to submit changes to the project. This process needs to be documented and everyone should be aware of the steps to take if they have a feature, they feel is essential to the project.

The way changes management is handled usually depends on the size of the project.

Small Project

This is the usual approach, which can work well when you have a small project, and you working in an agile way. However the volume and scope of the changes may mean that the project is delayed and the team become disillusioned. The usual process is:

  • A change comes in from client usually by email
  • Project manager simply updates the project plan
  • The new plan is distributed to the project team

Large Project

Most large projects implement design freeze after the planning process, so all changes have to go through formal change management. This is great as each change is assessed on it merits and whether it materially affects the business case. The downside to this is that better solutions and fast feedback is very difficult to integrate. Formal change management usually follows:

  • Originator of the change fills in a change request form
  • The change request is entered into the change log and issued an id
  • The project manager assess the change for impact and documents their recommendations
  • The project board review the change and make a decision
  • The board’s decision is entered onto the change log
  • If the change was rejected the originator is informed with the decision and reasons
  • If the change is accepted then the project plan is updated
  • Change is implemented, documented and change log updated

A Happy Medium?

Our approach sits in between the two, we do have a formal change management process but it is less formal and only happens after the design phase which is quite collaborative and agile. During the design phase we work with fast iterations with lots of client feedback. Then once the system has been designed, planned and signed off, we have design freeze. If a change is subsequently requested:

  • All changes are placed in a Google doc that everyone can add to
  • Each change is then assessed by someone in the project team and it is placed into:
    • To change
    • Out of scope
    • Phase 2
    • Bug
  • When all the changes for the iteration have been added, we sign off and date the iteration and make the changes in the to change and bugs columns
  • We allow clients to have three rounds of changes/ iterations

The key to the success of any of these methods is making sure that EVERYONE understands the process and that there is someone who enforces the process. It is also very important to get sign off at the key decision points to document that everyone was in agreement.

Tags: , , ,
Posted in General | No Comments »

How To Wireframe

Monday, April 6th, 2009

Wireframes can be a great way to visualise your concept and get the client engaged with something other than a written spec, but what are the best practices? Wireframes are supposed to show where items will be placed, and the general layouts of the page. Doing this will save you a lot of time before you start the time intensive design phase. Using wireframes is a great way to begin a project, as it allows you and your client to focus on layout without the distraction of color, type and other design elements. Concentrate on what goes where on your web pages and the percentage of space that each element takes up, which can be determined by your client’s needs. Design is not important. Think about layout, functions and navigation. Think about who the wireframe is for:

  • Developers?
  • Client?
  • Designers?
  • Management?

We tend to build wireframes in HTML, but doing them on paper or in Photoshop is fine, the process is the same, to work out the layout and general structure of the site.

Wireframe Example

Wireframe Figure 1: Wireframe example (click to enlarge)

Tags: , ,
Posted in General | No Comments »

Why Do Projects Fail?

Saturday, April 4th, 2009

Following on from my post yesterday, I was thinking about the main reasons a project might fail. I have a lot of friends in project management and it was interesting to get their opinions as well.

Here are the top responses we came up with:

  • Too much change
  • Benefits take too long to be realised
  • Poor funding
  • Untested assumptions
  • Poor requirements gathering
  • Senior sponsorship is weak or lacking altogether
  • No risk planning or analysis
  • Poor stakeholder analysis or management
  • Over emphasis on technology
  • Projects not focused on delivering benefits
  • Lack of appropriate skills in the project team

I am sure there are lots and lots of other ones, but these are the trends that we have seen.

What other big reasons make projects fail?

Tags: , ,
Posted in General | 2 Comments »

Solutions Not Technology

Friday, April 3rd, 2009

Recently we have had a lot of requests to consult on existing projects that have not gone as planned, and while there are many reasons for a project to fail, we have seen a common trend.

Technology by itself is not a solution, all projects should either:

  1. Solve a problem or
  2. Take advantage of an opportunity

Some people adopt technology for technologies sake, always keep the end objective in mind. Technology is an incledible tool if you know what the underlying problem or need is that you are trying to solve.

Make sure the stakeholders and users of the final product are involved in the early phases of a project and they will keep you focused on the success criteria and critical functionality.

Tags: ,
Posted in General | No Comments »

Written Specs vs Prototypes

Wednesday, April 1st, 2009

No client wants to read long scoping or technical spec documents, they either do not have the time, or they do not understand the content within them. Written specs take a long time to write and for small to medium sized projects they might not be the best solution.

We recently have adopted a more visual approach to scoping projects. Instead of just supplying a written technical scope we are using drawings, design mock ups, wire frames and prototypes. Our new process is as following:
Prototype - Drawing

Drawings

We start off with the good old fashioned pen and pencil, rapid drawings, ideas anything that comes into our heads gets put on paper. This is a great way to set up the structure of the design and layout quickly and easily.

Wire Frames

The next phase is to build the basic blocks of the page, this can be done either in a graphics package such as Photoshop or in HTML. We tend to use large coloured blocks to denote areas of the page.

Design Mock Ups

The next phase is the refine the wire frames and skin them with a design, so that they look superb. This design phase is very iterative and involves lots of client involvement and feedback.

Prototypes

With our prototypes, each page is designed and marked up in HTML and JavaScript, but with no business logic or database, which creates a skeleton of the site. These screens are considerably easier to update based on client feedback, and make sure that the structure of the site is agreed before the code and data model are designed. It also allows us to use a highly iterative process when working with clients.

The education for clients is that after the prototype has been signed off, that is the what we will be delivering, we have design freeze after that point.

The advantage of this is that the client can see exactly what they are getting, and can engage with the functionality before it is built and it is too late. A lot of the time clients have their own ideas about how the software should work, and pays to get their input early and often while you are deisgning the system.

So no more written documents?

This approach has worked very well for innovative projects, where the scope of the project is not clear or not set. However we still provide written documentation as well to back up the prototype as there is simply no replacement for this.

This approach is not for everyone and will not work for large scale projects where a full and detailed project management plan will still be required, but for smaller projects the results have been amazing.

Tags: , , ,
Posted in General | No Comments »