Category Archives: PM Tools

Another New Favourite Software

Recently, I reviewed Trello as a fabulous, free Kanban tool.

Wunderkit LogoNow, I have seen another tool, equally good.  It is called Wunderkit, and it is great for managing, collaboratively or alone, simple projects.  It is not what the project management community would understand by the term “project management software”.  It does no programming or sequencing, but for small, simple projects that many of my readers carry out, it may be just the tool – easy to use, free, entirely web-based (so no installation needed and easy multi-partner collaboration) and multi-project capable.

Because it is as much a personal productivity tool as it is a project management tool, I’ve posted a full review on my other (non-projects/change/risk) blog, on my main website.  If it sounds like this tool could be for you, check out that article, here.

Wunderkit Workspace

My new favourite software

Not long ago, I did a round up of online project management software.  Since then I have discovered a great team collaboration tool.

It is not strictly project management software, but it is a great asset to any team collaborating on a small, informal project.  It is, effectively, an online Kanban board.  But it is a marvelously well executed one.

The software is Trello – available at  It was developed by Fog Creek Software.


Screen grab of Trello

It allows multiple users to be invited to contribute in real time to a shared workspace that seems to be hugely configurable. The two best ways to assess its capabilities are to watch the video on the homepage, and then to set up a free account.

You can set up as many boards (one is illustrated) as you want, and invite collaborators.  On each board, you can set up your lists (three shown). Then you add cards to each list and drag and drop them from one list to the next as the tack progresses.  Each card can also store a great wealth of information in the form of files, pictures, comments, checklists, labels and voting.

Pricing: It’s Free

I don’t know what their future pricing plans are, but when I set up an account, it was all free – all you can eat and no advertising.  I assumed they are figuring they will win some fans and some serious users by then – and they deserve to.  But no; here’s what they say on their blog:

Are you going to screw me later and make me pay for something I got hooked on?

No. You have my word that we will not give away our *free* service to
you as a trick and then later make you pay. First, we make good money
on our existing suite of products already, so we have no temptation to
change our minds. Also, that sort of trickery would cost us all of
the goodwill we’ve built up over the last 11 years of running this

We do eventually plan to monetize the service when we have a bazillion
users, but it won’t be by charging you for what we’re offering now.
Think freemium, or app store models…

It is easy to use and very practical.  And, the iPhone/iPad app is great too.  I don’t know if there are apps for other mobile devices, but as long as the have a browser, you’re there.


Finally, if you are into agile (which I’m not), here is what they say:

Is there a way to generate story points to use with my Agile team?

Kind of. I guess story points are an estimate of how long something will take to do. This falls into the idea of a custom property for a card that you’d like to have meaning. For example, if your Trello board was a Sales Leads board, you might want all your cards to have potential deal size $$$ on them. Right now we don’t want to cram Trello into any specific use, so something like this would have to be provided by a custom plugin (see the API question).

The “so what?”

I don’t know if Trello is any use to you, but my guess is it could be and my advice is to check it out straight away – it’s free: what’s to lose?  I love it.

The DCMA 14 Point Schedule Assessment

I like checklists.  Well constructed, they give confidence and a logical structure to our analysis.

So I thank Glen Alleman (again) for making me aware of the Defense Contract Management Agency (DCMA) 14 Point Schedule Assessment.  The DCMA is a Division of the US Department of Defense (DoD) and their assessment is a checklist of 14 components of a project schedule, with criteria to indicate where that schedule may be weak or strong.

It is clearly well thought-out for theDCMA’s domain, and may not be wholly apporpriate to other project contexts.  For your project, it may miss some checks, some of the checks may be less valuable, or some of the levels at which the assessment fails may be inappropriate.

But surely, a rigorous assessment of your schedule using an assessment tool like this is of great value to any project.  I commend it to you.

The 14 Points of Assessment

I am indebted to Ron Winter Consulting and Mohamed Hegab writing on the ICPM Blog for getting me up to speed on this.  Refer to the links below for more information.  This is my summary of what I learned from them:

Review your project schedule against these 14 items:

  1. Logic Check
    Dependency relationships
  2. Leads Check
    DCMA deprecates leads (negative lags) you may want simply to assess each on its own merits
  3. Lags Check
    Too many lags (5%) flags a risk
  4. Relationship Types Check
    Expect most dependencies to be “finish-to-start”
  5. Hard Constraints Check
    Too many fixed dates in your schedule creates risk
  6. High Float Check
    Too many tasks with high (DCMA uses 44 days) float suggests poor logic or control
  7. Negative Float Check
    Ron Winter’s paper gives examples of when, counter-intuitively, negative float may be appropriate, but DCMA deprecates it and it must, at the very least, ring big alarm bells
  8. High Duration Check
    Long duration tasks and the risk they pose is a hobby horse of mine.  DCMA again choose 44 days.  I deprecate any task exceeding 10% of remaining project duration (except, of course, in the final months!)
  9. Invalid Dates Check
    A simple logic check on stated dates
  10. Resources Check
    Are the tasks properly resourced (and budgeted, I would add)
  11. Missed Tasks Check
    Have tasks been dropped from one version of your schedule to another?  If so, this could suggest erroneous omission.
  12. Critical Path Test Check
    Does the software correctly handle extensions to critical path activities?
  13. Critical Path Length Index (CPLI)
    My reading of this is that it is another check that remaining float on the CP is positive
  14. Baseline Execution Index (BEI)
    This is a check on progress to date against baseline

For far better informed discussions, see:

The “so what?”

If you are not reviewing all elements of your planning critically, then as a project manager, you are subjecting yourself to hubris, you are exposing your project to additional risk, and you are, arguably, falling down on your job.  Adapt the principles of this check to your needs, but do carry out a review.

Risk Happens! by Mike Clayton“Risk Happens! Managing Risk and Avoiding Failure in Business Projects” is published on 15 July.  Learn more, on the Risk Happens! website.

Sign up for Mike’s monthly newsletter

Just let me know your name and email address, and I’ll send you valuable extra tips and thoughts every month.

Issue Management 2: Eight Disciplines

In Part 1, I took up the challenge to tackle issue management in a way that tackles one reader’s dismay at issues being “incorrectly logged, escalated, allocated severity, given owners, tracked, date and time committed, and closed properly”.

Now we move on to the substance of my suggested process, based closely on the Eight Disciplines method, widely used for problem solving in the manufacturing industries.

The Eight (+1) Disciplines

D1: Mobilise the Team

Get your issue resolving team together and brief them on the outcome of your triage, what they need to do, and any administrative matters like leadership and reporting.  Also secure the resources that they will need, and assign any individual responsibilities.  At this stage, you will also need to define the escalation route – from the team to you and upwards to your project director, sponsor, boss or client.  Update your issue log with the responsibilities and authorities you have agreed.

D2: Define the problem

During triage (see Part 1) you will have sought to understand the nature of the issue.  Now the team must investigate more deeply to understand rout causes and consequences.  There is a range of tools available – maybe later…
Again, update your log and report on findings.  Stakeholders may need to know what is happening and, even if they don’t need to know, rumour control may require that you let them know anyway!  Update your issue log with your new knowledge.

D3: Containment

You may find that the problem will deteriorate if not contained, so apply any temporary fixes that you need to buy the team time to search for a definitive resolution.  Update your issue log with the new status.

D4: Find the Root Causes

Now it is time to start on resolving the issue for once and for all, so investigate back through the chain of cause and effect to trace back as far as you can to the root causes.  Be careful to avoid being seduced by correlations that are not causal – now is the time to evaluate and test rigorously to ensure your understanding is robust, because this will be the basis for…

D5: Plan Permanent Corrective Actions

In this step, I advocate looking at multiple options for correcting the issue, where they exist, and evaluating which is the most cost-effective.  It is likely that you may need to make compromises between different solutions, none of which is perfect.  Use your project’s documented goal and objectives as the basis for your decision, and escalate your decision as necessary.  Once you have selected your solution, develop a plan to the level of detail that allows you to be confident that implementation will succeed. Update your issue log with your decision and document your plan if it is substantive or requires change authorisation..

D6: Implement Permanent Corrective Actions

I would include monitoring and review in this discipline.  In a changeable project environment, it is dangerous to assume that the resolution you planned yesterday will be equally applicable tomorrow.  Update your issue log with the new status.  Close the issue if testing shows it to no longer threaten your project.

D7: Prevent Recurrence

The Japanese have a term that is transliterated into English as “Poka-yoke” and means mistake-proof.  An example of poka-yoke engineering is in the wiring looms of modern cars, where each circuit’s plug/socket pairs are different.  Another is the asymmetry of a SIM card or SD card, making it impossible to put them into their slot incorrectly and hence make the wrong electrical contacts.  Older readers will recall the break-off lugs on VHS and audio cassettes that prevent over-recording.  If you can find a way to prevent the issue ever recurring, this is a real bonus – although D7 is clearly more relevant in a process environment than a project context.  If you need to make a change, take it through your normal change control process.

D8: Celebrate your Team’s Success

… or at least recognise their effort!  Acknowledge what your team has achieved collectively and individually, share it publicly as appropriate and fin ways to consolidate any lessons learned both personally and institutionally.

The “so what?”

The Eight Disciplines approach to problem solving – adapted suitably and combined with a triage at the start makes an excellent process for project issue management.  It is not the only process that can work, by far, but a good process is better than none at all, and a flaky set of notes in an ill-maintained issue log, and no follow up nor sense of responsibility.

Free Mini Guide: 8 Disciplines Process Summary

Sign up to my newsletter and I will send you my free summary of the Eight Disciplines process.

Issue Management 1: A Matter of Discipline

I have been challenged to write about issue management by a former colleague who says that he sees so many examples of how project issues (mostly linked to large ERP projects) are “incorrectly logged, escalated, allocated severity, given owners, tracked, date and time committed, and closed properly”.

Issue Management


Now I feel some pressure, as David has already articulated the bare bones of what project managers are taught.  So I need to get serious, and that requires discipline.

First, defining “issue”

What is an issue and how does it differ from a risk?  The single differentiator is certainty – a risk is an uncertain event that may effect outcome,whilst an issue is an event that may effect outcomes.  Let’s be more formal.  A risk can be formally stated in terms of four components:

  1. Root causes
    Pre-existing conditions that make the occurrence of a risk possible.  These are why fellow blogger Glen Alleman is clear that there is no such thing as “unknown unknowns”.  The condition is there and knowable – albeit with a potentially high threshold for discovery.
  2. Trigger
    The circumstance that can set about the event by disturbing the root cause conditions.
  3. Risk
    The event or change we are concerned with
  4. Consequence
    The change in outcome – which can be adverse (a threat-type risk) or positive (a benefit-type risk)

For an issue, the trigger has occurred, so there is no doubt that the risk event will happen – although there may be uncertainty about the consequences.


What process can we use to manage an issue?  For me, the best approach is derived from a problem-solving methodology that is well known in many areas of industry – in particular, the auto-manufacturing sector, where it originated.  This is the “Eight Disciplines” method.  I will describe it here, as adapted to issue resolution.

And the essence of any issue management process must be in “resolution” – taking action to deal with the issue.  This is not to suggest that the governance matters of authority and record-keeping are unimportant, but merely to suggest that they are the “tail” not the “dog”.  Too many PMs get caught up in these and let the issue run away with their project.

D0 (D-zero)

There are eight disciplines, but in my training, I have introduced a ninth discipline, “D0”, before starting with what is normally regarded as the first, “D1”.  I am a passionate believer in the concept of “triage” in a project setting.  In this case, as soon as you become aware of an issue, there are four triage activities you must take immediately, to assess and prioritise the matter.

  • Safety first
    Is there an immediate threat?  If so, deal with it.  Take emergency action.
    We may be talking about life an limb, but this may also be about operational integrity, regulatory compliance, reputation or any other “must-do” concerns to your organisation.
  • Marcus Aurelius next
    Marcus Aurelius – Roman emperor and philosopher – said that we must understand the true essence of all things.  What is the issue?  What is the issue?
  • Prioritise
    Set your priorities in terms of time to deal with the issue, resources to deploy, and importance compared to other issues and planned activities. If you will need authority to act in accordance with your prioritisation, then document your evidence and reasoning.
  • Goal and Objectives
    Set your goal and objectives for resolving the issue: what does “resolved” require, and what are the time, cost and quality criteria you will evaluate your performance against?

Start your entry in your issue log by recording your emergency actions, your understanding of the issue, your prioritisation and your goal and objectives.

Eight Disciplines

Your emergency action may have fully resolved the issue – but that will be rare.  Now you are ready to pursue the eight disciplines.  For that, you must see Part 2.

The “so what?”

Issue management calls for discipline.  Filling in an issue log and turning half your attention to the matter will rarely give just the right amount of focus.  Start your process with a precise triage of the situation, and then you will be able to act according to a true prioritisation.

Click her to go to Part 2.

WBS – a short rant

Well, not a rant really; more a lament.

It is actually a lament about how the fact that language is used differently across the two sides of the Atlantic can cause misunderstandings and, well…  rants.


I have been mystified for a while, about why some bloggers have commented – sometimes vehemently – on the need for Work Breakdown Structures to show deliverables, when it seems obvious to me that a WBS is a Work Breakdown Structure and, as I was taught, contains the Work or activities of the project.  It is a PBS or Product Breakdown Structure that contains the Products or Deliverables.

Shift Happens!

As I was researching for my forthcoming book on Project Risk Management, “Shift Happens!” I checked out the PMI’s PMBOK Guide (Fourth Edition).  This defines the WBS as a “deliverable-oriented hierarchical decomposition of the work…”

So what then is a PBS?  PMBOK does not define it, and so I see what has happened.  In the UK, we define (in “Managing Successful Projects with PRINCE2” Fourth Impression) a PBS as “A hierarchy of all the products …”

The “so what?”
Two nations divided by a common language

So we are all right.  A WBS focuses on the activities here in the UK and on the deliverables in the US.  Who knows about elsewhere?

Earned Value Aide Memoire

As a consultant, I quickly learned the value of having tools and techniques at my finger tips.  Glen Alleman recently described the way that, in the environments that he works in, contractors gather many “badge tags” on lanyards around their necks.

I didn’t, so had to keep a handy little notebook in my bag.  I seized on my first Palm Pilot in 1996 to put all that valuable info into my jacket pocket, including a crude representation of a scrappy image showing the key concepts of Earned Value Analysis (EVA).

In truth, I rarely used that information. Most of my readers will not be users of Earned Value Management (EVM) methods either.  However, knowledge is power, they say.  Certainly, the ability to quickly access and deploy a technique as powerful as EVM will give you more control over your project, so:

  1. Make sure you understand EVM methods.  Take time now to research it.  Sadly, I am no expert, so shan’t be offering that information here.  Look to others who are – like Glen.
  2. Get yourself a cheat sheet to ensure you can access the definitions accurately as soon as you need them.

… which is all a long way round of saying:

EVMCheatSheet1Glen Alleman has posted a fabulous EVM resource on his blog.  All the key definitions of EVM on two sheets.  Glen suggests printing them, laminating them and putting them on your lanyard.

I shall be downloading them, turning them into a pdf, and putting them on my iPhone.  My carrier may not provide reliable signals, but at least, unlike Glen, I am able to take my phone onto my clients’ sites.


The “so what?”

Thank you Glen.  If any of my readers are also EVM users, do take a look, and acknowledge Glen’s generosity too.