First time visitors read!

If you are new to this Blog, read about it's purpose and how to get the best from it

Free Project Management Training

Go through the site content in a structured manner to teach you Project Management or improve your success rate

No English?

Can't speak English? No problem!!

Why the Sheepdog Analogy?

A Project Manager is a necessary evil. Why? Well, the PM doesn't produce anything - write code, lay concrete or whatever. However, don't have one and see what happens!

Always telegraph your Punches as a Project Manager

Sometimes as a Project Manager you need to throw a "Project Manager punch" but not a literal one please!

Isaac Newton's contribution to Project Management

Newton's laws, especially his first law of motion, should be as important to a Project Manager as it is to a Physicist. Why?

O Sponsor, Sponsor! wherefore art thou Sponsor?

You are given a project to run. Amongst your early questions should be, "who is the Sponsor?"

Always remember the Human side

It is very easy to get hung up in the technical and management side of Projects and forget that they need to be delivered by human teams. So "Always remember the human side" is the key phrase!

Why writing a Project Status Report is not a chore

I've met several Project Managers who view writing any Project status report as a chore. I think the opposite.

Planning is the key Project Management discipline

I have been asked a few times, "What are the top xx things to focus in on as a Project Manager? If pressed, I always fall back to Planning

Friday, 16 January 2015

IT Build Sheet for SDLC Build phase planning and monitoring

One of the key elements in an IT Project SDLC is the build or construction phase. How do you plan & estimate the duration of this phase and equally important how do you monitor that it is still on track when you have baselined your plan? Although there are various ways you could tackle this, my proposition is that the spreadsheet based Build sheet I have designed has various key benefits over other approaches as explained in this post.
Project Build Phase - Build Sheet in use

Estimating the Build effort

When putting together your IT Project plan, you need to estimate your Build phase (typically including Unit Testing). The classic approach to doing this is bottom up estimating using expert judgement (also have a read of my post on Estimating in general). So decompose the business requirements into required system changes, decompose further if it aids estimating and then have your experienced developers / designers estimate the effort required considering local quantity processes.

Your first baseline of the bottom up estimates will be during the Project initiation phase and may be a fundamental part of estimating the overall project effort (if an expand from construction estimating model is utilised) 

As you move through the development lifecycle prior to Build commencing a lot could happen which may affect the estimates, requirements definition, technical design etc. I would maintain 
  • the original initiation level estimates
  • the revised estimates out of analysis and design

Benefits of approach

Clearly the objective(s) could be achieved through a scheduling tool such as Microsoft Project or Open Workbench especially if actuals and estimates to complete (ETC) can be automatically fed into the plan (e.g. Microsoft Project Server or Niku). However, such an approach requires the tools in place, the time and skills to use the tools and in terms of the integrated systems, a certain level of organisational sophistication which is fairly rare in my experience.

The benefits of the Build sheet approach I have developed are that:
  • It is simple to use, little training is required
  • It relies only on spreadsheet software such as Microsoft Excel
  • It can be handed over to a Development Team Leader to maintain and supply back to the Project Manager periodically, ideally via the Project File. Thus it becomes a key part of your Monitoring and Control approach

Build sheet concept explained

I will show you a worked example in a separate post but firstly I wanted to explain the concepts behind the Build sheet. In a short sentence it is examining the balance between SUPPLY and DEMAND within a workbook:
  • Supply - the available resource to undertaken the build
  • Demand - the Estimates to Complete (ETC) for each element of build scope / effort
In terms of units, I tend to use hours but other units could be used.

Supply side

A worksheet within the workbook shows the following:
  • a list of resources and their % availability across the build cycle [rows]
  • the days of the proposed build phase (with some extension past the due end date) [columns]
  • special inputs - D(ay)/Start - this defines the cell that represents the current day position in the build cycle (when in planning mode this is the planned start of build but note this will change during monitoring and control)
  • special inputs - D(ay)/End - the planned end of build phase day (for the individual resource if needed)
Some simple spreadsheet calculations allow the Supply per resource and in total to be calculated.

Demand side

A worksheet within the workbook shows the following:
  • items of build scope [rows]
  • build order / estimates (several columns if estimates are executed at different points in lifecycle) [columns]
  • scope items can be either unallocated or allocated to the resource names (from the supply worksheet) entering an Estimate to Complete (ETC) figure per person per scope item [columns]
  • the unallocated item estimates are taken from the most recent estimate column
  • at the bottom of the worksheet some simple calculations allows to show per resource Demand (total of ETC allocated to an individual) and Supply (taken from the other worksheet) and a difference
  • in addition a yellow box calculates overall whether there is any supply left over when ALL the demand (allocated and unallocated) is considered making the assumption that the resources can pick up any scope

Conclusion

Although you can plan and monitor a SDLC Build Phase with traditional scheduling tools, I believe that a spreadsheet based Build sheet balancing Demand (things to be done) with Supply (resources available to do the things) offers a number of key benefits. If I have intrigued you sufficiently, please take a look at the worked example which will make things clearer.  

IT Build Sheet for SDLC Build phase - Worked Example

In a previous Post I have suggested a Build spreadsheet approach for planning and monitoring an IT SDLC build phase. In this post I take you through a Worked example to make things clearer.
Project Build Phase - Build Sheet in use

Worked example


The example assumes a build phase from 06/01/2014 to 07/02/2014 although as you will see this is easily adjusted.

1 - Define Supply side and likely build phase duration

Build Sheet example - Define Supply side and likely build phase duration

Firstly we create the SUPPLY side. Key points are:
  • The worksheet (columns P onwards) has the days of the week and the base hours per day, 8 in this example and 0 at weekends. 
  • The most complex element of the spreadsheet is the columns coloured in Blue where the availability period for build is defined through cell references. In this example, I defined the build phase as 06/01/2014 to 07/02/2014 (the use of cell references allows easy modification which is necessary as will become apparent)
  • There are 3 developers Joe, John and Richard. Joe is only available 70% of the time and John 60% in this period as they have other duties. Richard however can be dedicated 100% to this work
  • A sum of the cells P onwards for the period defined in Blue gives 140 hours supply for Joe, 120 hours for John and 200 for Richard

2 - Enter Demand side scope and bottom up estimates

Build Sheet Example - Enter Demand side scope and bottom up estimates
























In Step 2 we enter the Demand in terms of scope items. In this example, I have entered 9 modules with "expert judgement" estimates (both during Initiation and after Analysis & Design), the order in which the modules should be built, any dependencies / comments.

At this stage, nothing is allocated to a resource although if there were heavy skill set constraints you might need to do this. For this exercise, let us assume in the main, any resource could pick up any piece of work.

The Demand is consider "Unallocated" but a comparison of total Supply and Demand is carried out by a few simple spreadsheet calculations which shows that we are broadly in balance (actually a whole 4 hours spare supply!)

If the Supply wasn't in balance with Demand, assuming we aren't going to reduce estimates (not a recommended strategy), we need to either:
  • descope Demand
  • increase Supply (extend duration of build phase, add more resources, work overtime, have a higher allocation to the build etc)

3 - Allocate Demand to named resources

Build Sheet Example - Allocate Demand to named resources




















In Step 3 we allocate scope to named resources. In the example, I have started with the initial build order and you can see that in one case, I have split some scope between two resources. 

This is a good reason why the sheet should be handed to the development team lead as detailed knowledge of the technology will allow decisions to be made as to when work can be split between several people and when this is impractical. 

When the work is allocated out, the "Allocated" cell is changed from No to Yes so that the Demand isn't included twice in error (Allocated and Unallocated). You should note that you can check the Supply/Demand balance both at an individual level and overall (considering unallocated build scope).

Based on this setup (i.e. there is enough work allocated to each resource), this allows build work to commence. It is an individual choice whether you should allocate out all scope or keep some as unallocated. The logic of the latter approach is that things don't always go to plan and so you might need to change allocations during the build phase if everything is fully allocated.

4 - End of week 1 Monitoring & Control

In step 4 we look at monitoring of progress against plan. It is now the end of the first week (although you could monitor daily if you want). So build commenced on Monday 6 January 2014 and it is now Friday afternoon 10 January.

The Development team leader speaks with their team and the build sheet and establishes the picture. Estimates to Complete (ETC) should be captured from the start of next Monday i.e. ask "EXCLUDING the rest of day, how many hours effort do you need to complete this element of scope?"
  • Joe has finished the build of scope id S01 (Module A) and is part way through the Unit testing although this has proved more problematic than originally thought and the best view is that this will be complete on Monday i.e. 8 hours remaining
  • John has made reasonable progress on S03 but believes another minimum three days effort is required. The development lead believes this is a bit optimistic so notes 28 hours ETC
  • Richard has completed the build of scope id S05 and believes he will complete the unit testing (S05UT) on Friday afternoon or first thing Monday morning. A cautious estimate of 2 hours for Monday is noted.
Armed with this data, the Development team lead can update the build sheet.
Firstly, a reduction in SUPPLY needs to be made as one week has elapsed.
Build Sheet Example - Monitoring, changing Supply side












Next, the DEMAND side can be updated.


Build Sheet Example - Monitoring, updating Demand side

























The date started and date completed can be entered with ETCs updated in line with the meeting held (see above). I would keep the ETC as 0 for completed scope to identify who did the work. Once all the updates have been made then look at the difference between the Supply and Demand both at an individual resource level and also considering unallocated work. With this example, much of the scope has been left unallocated so the sheet shows 7 hours shortfall in resource for the current ETCs.

The next step is to decide what to do about the shortfall, possible strategies might be:
  • organise some overtime to get back to balanced position (or better) as soon as possible
  • add resource
  • deliver build late (the least favourable option)

Conclusion

I hope this worked example shows the basics of how to use the Build sheet and the simplicity of the approach. I know from its use within multiple Projects I have run is that Development Team leads can operate it effectively and as a Project Manager it gives me visibility on progress and whether we can still hit the end phase milestone. You should be able to write your own version with some simple spreadsheet skills.

Tuesday, 6 January 2015

Use Formal Entry meetings for any critical Project phase

If you have an important phase of tasks in your plan consider the use of a formal gated entry meeting to judge whether you can commence. I believe this has great value and in this post I will take you through how I approach with an example.
Projects - Gated Entry in Operation

The Entry process

  1. Well in advance, draft, review, agree and document the criteria by which the entry gate meeting will judge whether the project is in a fit state to ENTER.
  2. Publish this list with ownership for each criterion
  3. Send out updates in advance of the meeting with a RAGB status (Blue = complete / signed off)
  4. Organise the meeting with appropriate stakeholders and each criterion owner if not confirmed complete before the meeting
  5. Walk through one by one and discuss
  6. If the criteria are not fully met it is still possible to make a decision to enter the next phase if the risk profile is not deemed excessive. The important point is that the decision is being made after review and with eyes open for residual risks to manage
  7. Alternatively the meeting may decide that the project shouldn't enter the next phase at this point. Agree whether another meeting needs to be scheduled after some actions have been achieved or to delegate to the Project Manager based on the actions being complete
  8. Document and manage any actions identified from the meeting including adding Risks(s) to the RAID log if necessary
The value in this approach is to be objective in advance of the point in time when the pressure is always to "get on with it". It also acts as a motivator to the criterion owners on what they need to achieve.

An example

Here is a very recent example I have used in an IT Project for entry into an Operational Acceptance Test (OAT) phase after completion of Systems and Integration Testing (SIT) and User Acceptance Testing (UAT). The criteria in themselves are not what I want you to focus in on, I'm sure your project will have different ones. It is the value of the process which I commend to you.


Example Phase Entry Criteria




Project / Programme Gates

The ultimate Entry process is a Project Gate where the whole Project is formally assessed at certain points to see whether it is viable. This can happen in conjunction with the use of PRINCE2 Stages so that as part of the Stage boundary, several aspects of the Project are assessed including a check that the business case is still valid.

Such Entry Gate reviews can be internally held (e.g. undertaken by the managing Board with potentially some peer reviewers outside the Board) or can be externally managed. A good example of an externally run framework is The OGC Gateway Process which anyone who has worked in major UK government Programmes and Projects is likely to have been exposed to. This is a gated review undertaken by people totally external to the core team / governance.

And don't forget...

I have spoken about the Entry Gate concept but sometimes it is better to position as an Exit Gate although an exit is typically an entry for the next phase!

Twitter Delicious Facebook Digg Stumbleupon Favorites More