Planning and delivering development tasks into the project schedule with sticky notes and Google Gantter. Report from the battlefield.
Every Project Manager faces different challenges with planning scope and sticking to the deadlines. In this article I suggest we look into a couple of case-studies that I have used from my own experience. Therefore, this is an actual “report from the battlefield” and I hope you gain a lot from it, just like I did.
Case-study 1: Building a WBS
Company X is a manufacturer of custom Web-based software and Mobile applications. As a Project Manager I managed a software project the major goal of which was to create a website enabling users to view open vacancies and send their resumes to open positions. This case-study is a guide through the process of creating the WBS for our project. Assume that I had already had the inputs to the WBS, such as project scope statement and scope management plan, organizational assets such as policies and procedures. The first step I took was to call a WBS meeting with my project team. The project team consisted of such specialists as designers, frontend and backend developers and test engineers. I explained to my team that the purpose of the meeting was to create an initial work breakdown structure to represent all of the deliverables for the MVP version. My goal in the meeting was to determine major categories of deliverables within the sprint. The team identified that this project had several major categories of work bound to the major components of the website both high level and project management deliverables:
- Web-application components
- Design work
- Frontend work
- Backend work
- Testing work
- Project management deliverables
These categories captured all of the items that my project team and I would create. Note that one of the categories included are project management deliverables; this is important because it required me creating documents, estimates, and communications to inform future project managers and enable them to improve their work. Project management deliverables were intended as future historical data.
When creating our WBS, I wanted to use a special system to identify each element within the WBS. The name of each element contained three main identificators:
- Name of a High level component (Pages or screens)
- Name of a sub-component
- One of the four major categories of work
I had Anastasia, a project team member, draw several segments onto the white board. Each segment reflected one of the major high-level deliverables named appropriately. Next my team and I began decomposing major deliverables into smaller components. As the team had reached consensus on each deliverable, I arranged a sticky note in the appropriate category. Here’s what our WBS components looked like at that point:
With the WBS beginning to shape up, the team decomposed the deliverables yet again. My project team followed the 6-8 hour Rule: the smallest item in the WBS should take no longer than 8 hours and no less than 6 hours to create. Through rounds of decomposition, the project team managed to build a robust WBS that depicted all of the project deliverables. After the WBS was put together I transferred the WBS from the sticky notes into Redmine and Google Gantter, as set in a company project management tools. Redmine based WBS served as a tracking base and at the same time as a dictionary so the project team could ask for details on each of the project tasks and add time estimates.
Case-study 2: Creating the Project Schedule
After the WBS had been created it was time for PND (project network diagram). We gathered for the next round of planning with the goal to determine a minimal duration of the planned work and the entire project. For this matter my project team and I had to answer three major questions:
- Which work exactly were we going to start with in each of the categories for the major deliverables:
- Design deliverables
- Frontend deliverables
- Backend deliverables
- Testing deliverables
- Project management deliverables?
- Which work exactly were we going to proceed with after the end of each part of the previous work?
- How different types of work were connected to various deliverables (successor and predecessor relationship)?
In order to figure this out we arranged the sticky notes with all of the decomposed work on the white board and linked them to each other in a sequence order, taking into account the logical connections between the types of work. When the team finally agreed on each sequence, I arranged the sticky notes in the appropriate line. Here’s what their NPD components looked like at that point:
After all of the work was sequenced, I started setting appropriate relationships within the work in my Google Gantter file (that I had earlier created before we finished the WBS creation). Adding the sequence of the work and time estimates to Google Gantter gave me the first insight on how long it would take to finish the planned scope. But, before I could set the precise insight about the project duration, I had to deal with several important things like:
- Project dependencies, such as vendors and people;
- Availability of resources, specifically developers;
- Setting a project calendar (weekends, holidays, lines of business and other possible setbacks of the project implementation);
- Setting a resource calendar;
- Project risks and their effect on project schedule.
Setting a project calendar
A project calendar describes when project work can take place. The project calendar is often defined by a manager or the customer, but it may sometimes be determined by the project manager alone. Most software development projects occur during typical business hours: Monday through Friday, 8:00 a.m. to 6:00 p.m. Nothing fancy. Imagine a developer, however, who’s been placed onsite to complete a portion of the project. A customer may request that the developer works only between 8:00 a.m. and 4:00 p.m. In this instance, the customer has set the project calendar working time. Now throw on top of this all the company holidays when your staff is off – that limits the project working time even more.
You should examine your project calendar to predict when the project will be complete. Your project may end up taking much longer than expected because of setbacks like holidays and weekends.
Setting resource calendar
Your project team members have their life beyond the project. They may have vacations, doctor appointments, sick kids, or something else personal. In addition, your project team mates may be working on over one project at a time, so sometimes they can’t allot all of their working hours to your project.
As you build a resource calendar, which identifies when the resources you need are available to do the project work, you need to bear these factors in mind. The resource calendar conveniently takes into consideration multiple projects, holidays, and time away from the project. More likely than not, the resource calendar input to the project schedule will increase an overall project duration, but not the amount of man-hours needed to complete the project.
At this stage the only remaining thing is to evaluate the influence of the project risks. Eventually, in our case, when all of the facets of the project schedule were covered, my project team and I had a possibility to obtain a realistic date for the project completion as well as planned start and end dates for all of the project work and milestones.