Help regarding creating a WBS for an Application

Question

I'm trying to build a work breakdown structure for a project I'm working on and since this is my first time doing something like this I was wondering if I could get some guidance.

The application I'm working on is a simple task list web application which has:

• an authentication module that has two roles for authenticated users (admin/user)
• a simple create a task screen
• a search for a task screen
• a dashboard that graphically displays tasks
• some simple basic reports
• some advanced admin reports

Can someone help me get started on a WBS for something like this?

Thanks for any help

Answer 1

Actually you already made the first step. Your list looks pretty well as a top level of WBS. Another step would be decomposing these features into lower-level tasks. For such a simple application I would probably end up with only a couple of levels on WBS and wouldn't try to split any further.

Example of what I'm talking about could look something like:

Authentication module
    Database design
    User list
    CRUD for managing users
    Log in screen
    Mechanism to verify permissions (access to specific function)
    etc.
Task management
    Database design
    Task list
    CRUD for task
    ...

Note: here's what I understand as CRUD

You should end up with simple hierarchical structure which represents fairly well what your app is going to do.

UPDATE (After Stephan's answer): What I assumed here was that every feature (database design, user list, etc.) is a deliverable, which means at the completion of the feature you have it working: tested and deployed (if you work on web-based app). It is approach used often in agile approaches where you often try to complete whole production cycle on feature-level and avoid splitting the project into phases: design, development, testing, deployment, etc.

Answer 2

I agree with Pawel to keep your WBS for this project as simpe as possible. A WBS is deliverable-oriented, so I would not add the individual tasks right away. Tasks are added in the next step when you have a clear understanding of the full project scope.

Focus on every deliverable that needs to be produced in order to come at the end of the project. Project scope includes both the product scope and the supporting processes to create that product.

Everything that is not included in the WBS is out of scope and will not be done.

So my WBS for the above project would look something like this

1. Analysis
    1.1 Requirements analysis / Product backlog
    1.2 Domain Model
2. Application
    2.1 Authentication Module
    2.2 Task screen
    2.3 Search module
    2.4 Dashboard
    2.5 Reporting module
         2.5.1 Basic reports
         2.5.2 Admin reports

In principle you could break it down further to each individual report, if that would be appropriate. Size of each deliverable is important here: if one report only takes an hour or two or it is only a single task to develop one, than this level might be too detailed for follow-up. That is the idea behind the WBS: you break it down up to a level of detail that makes sense for organising your project. The lowest level is the work package level = a deliverable that you can further break down into tasks, like Pawel did. Detailed analysis can be part of each deliverable, or combined into a single deliverable (requirement analysis document for instance), depending on how you will organise the project.

Next you have to add the other processes that surround the creation and deployment of this application. That might look like the following:

3. Deployment
   3.1 Testing
       3.1.1 Test scenario's
       3.1.2 Final system tests 
       3.1.3 User Acceptance testing
   3.2 Deployment
4. Documentation
5. Business Roll-out
   5.1 Support organisation
   5.2 Training
   5.3 Communication
6. Project Management
   6.1 Project Charter
   6.2 Status reporting
   6.3 ...

The next step is to write down a few (or more) sentences about each element of your WBS (called a WBS dictionary). It doesn't have to be a complete analysis, but it should help everybody understand what is going to be done (eg for training: are you going to write a complete manual, an online help file or just some powerpoint slides with some screenshots; the same with the reports: list the number of them and a fwe words about their contents, ...). The aim is to have a clear understanding of what will be realised.

Answer 3

The other answers cover the obvious items for a WBS. I would add some preparation items to the WBS. Things to consider are:

• Selection and setup of servers.
• Selection and setup of revision control system.
• Selection and setup of bug tracking system.
• Selection and setup of automatic build system.
• Selection and documentation (or review of) processes.
• Selection and implementation of framework(s) and libraries.
• Selection and setup of project Wiki or CMS (content management system).
• Selection and setup of development tools.
• Team selection.

Once an organization gets it processes under control, then several of the can change from "selection and setup" to "add project to" or some similar simpler task. Letting these things just happen usually means they don't happen or aren't available when needed. You may need temporary resources to perform some of these things.

Answer 4

In order to build a WBS for a software development project you need some SDLC framework. For example RUP or MSF. They will tell you exactly what deliverables and work packages shall be placed in WBS.