Delivering projects is a tricky business, achieved by skilled practitioners in their field – be it software development, events management, construction, oil & gas etc. It is the wonderful individuals who work on projects who deliver the output that will ultimately mean the project meeting its business case. However, the reality is that not all team members will be an expert in every element of their discipline when they start on the project – they will all have strengths and weaknesses. But how do you know those strengths and weaknesses so you can plan for them, exploiting the strengths and mitigating the weaknesses? This is where a role & skill assessment can come in; this activity can be performed at the Project level initially during project start-up, documented in a large table or spreadsheet, or perhaps at a wider organisational level in some sort of resource planning tool.
 
The first step of this is to have defined roles within your project or preferably your wider organisation. Rather than having anybody do almost anything, project teams tend to have individuals who work in specialisms: be it plumber, software tester or project manager. These roles need to have clearly defined roles and responsibilities, tasks which are expected to be completed, and criteria which they are assessed on. Without these it is impossible to then identify what skills are associated with them, and thus ensure your team is skilled appropriately.
 
Step two is to identify skills which are associated with each role, or even skills groups, so that we can then assess team members against them. For a software developer for example, we may have a group relating to software languages (Jave, C# etc) a group relating to processes (code reviews, unit testing etc) and a group relating to soft skills (team leadership, facilitation etc).
 
Step three is to then use some sort of scale to rate individuals for each of their skills. We’ve seen 1-10 scales used before, but in your profession can you really identify the difference between a 6 and a 7? If not then consider using a word based scale such as : Untrained, Trained, Competent, Highly Competent, Expert. Don’t see or define this scale in any way in which is may be seen to be rating less experienced team members in any sort of negative fashion, but try to put definitions round what each level means for each skill and make it clear what individuals need to achieve to move up to the next level.
 
Step four is where you actually do something with the information to put it to use: we need to ascertain what skills levels we actually need for each role in our project, and identify gaps vs the skill levels of resources we actually have available. Perhaps we don’t have a sufficiently skill resources, so we know we either need to hire a new team member or organise training and development for our existing team. Alternatively, perhaps our resources are too experienced and we only need some basic skill – we could be tying up expertise that could be better used elsewhere or paying over the odds for talent we don’t need, damaging project margin.
 
How to you identify and plan for your team’s experience and expertise? Let us know your thoughts in the comments below!
 
Stay Healthy - Project Health Check - projecthealthcheck.org

Kanban is something that features in both Lean Six Sigma and Agile software development. It descended from the Lean improvements of the Toyota Production System, and is a proven approach to optimise effectiveness of a production line system. How then can it be useful for a project manager, if it’s about production lines for motor vehicles I hear you ask? Well, for software development projects at least, the software development life cycle of individual software “features” is very much like a production line. Ok, so you aren’t creating the exact replica of a specific part over and over again - they will vary. But if features are segmented such that they are all of a similar size and complexity, the production line approach can work.

What’s the value of this production line approach? Simply, it’s the speed of throughput - or Lean Cycle Time. Ever had a of scope item/task/work package just drag on forever, with the percentage complete painfully increasing by just a couple of imprecise percentage points per day? Ever just want to get stuff moving and feel like work is reaching a completed state? Kanban may be for you. It links to Agile because Agile development is all about delivering early value to the customer and incrementally improving it with further deliveries - incremental delivery. The Kanban production-line system focuses on getting throughput in the software development lifecycle, so stuff gets “done” (remember: we need to define that in agile!)

So, what are it’s jet features and how does it work? I’d highlight two critical components:

(1) Visual Kanban Board - Kanban uses a visual board to bring attention to the startus of each item that is Work In Progress (WIP), and uses columns to delineate the progress with each column representing a phase of production. An item is recorded in a “card” that starts in the left hand column and progressively moves through each column, representing each stage in the process until it reaches the right hand side and is “done”. In the software development lifecycle these will be things like: backlog, selected for development, in development, testing, user testing, implementation, done. The precise columns can be more extensive, and some organisations would use two columns m for each phase: “Waiting” or “In Progress”, meaning that waiting time (which in Lean is Waste) can be more clearly identified. M I’d recommend you document in your project approach/tailoring the precise standards around each phase: Input & Output Criteria and Evidence Required at each stage (test scripts, approvals etc)

(2) Limiting Work In Progress (WIP) - While the Kanban board is a visually arresting part of the approach, the real key lies beneath the surface in how it limits production in the system. Kanban knows that there will be natural bottlenecks in certain stages of the process, so pushing more work to in progress that can pass the constrained part of the process is pointless - it won’t speed up delivery, is just wasting resources, diverting attention and adding complexity by having more plates spinning. Kanban lImits WIP by only allowing so many items in production in any one time, achieved by limiting the total number of work cards on the board, or by only allowing so many work items in each column of the Kanban board at any one time. The focus is then on expediting the few items that are WIP before looking at new scope; this is achieved by reviewing the Kanban board in a right-to-left manner and the potentially using approaches such as swarming - having many people focus on a single item. When reviewing the board, ask: what do we need to do to get the items neatly done across the finish line? Then as we move leftwards through the columns what do we need to do to get each item moving to the next column along? Only at the end of this process do you reach the left hand end of the board and then consider bringing in new scope into WIP. In this way Kanban is regarded as a “pull” system rather than a “push” system.

What are your thoughts on Kanban and have you had much success in implementing it on your projects? Let us know your thoughts below!

Stay Healthy - Project Health Check - projecthealthcheck.org