Entries in PM (13)


I'm Sharing on Flipboard

I'm now sharing news and articles I find interesting on Flipboard - https://flipboard.com/@gavinknight


Identifying Risks via Assumptions

It was some years ago, early in my project management career, and I was in the early stages leading a particularly challenging client engagement for a consulting firm.

I went to the partner, my boss, and told him we simply couldn't deliver the project the client had asked us to deliver due to information we had not previously been aware of. The project was to implement a supposedly already built system - but it turned out it was nowhere near ready, and was probably never going to be due to a fundamental flaw in how it had been designed.

While he understood why I was saying this he refused my request to pull out of the engagement. His view was that it was simply too late to go to the customer with such a high level analysis. Initially I was very frustrated by this response - why insist on continuing with a project that was going to fail? But my boss took me beyond that.

He challenged me, "if you make enough assumptions, do you think we would deliver the project for the client?"

I said I believed we could, but I that I didn't think the assumptions we would need to make were viable. Some, if not many, of them will fail - or, possibly already had (e.g. that the system was ready).

He said, "that is fine, for now, let's work out what the assumptions are and take them to the client. The client will then easily agree with why the project either has to be abandoned, or dramatically re-shaped".

So, we stood around a whiteboard and listed all of the assumptions we would have to make for the project to have a chance of success. It was a long list!

We then went through each and rated them as either having already failed (the assumption was no longer true, if it ever was) and for those that were still true (the assumption was still valid) work out the likelihood that each would continue to be valid for long enough to deliver the project, and what we could do to increase the likelihood of that being the case.

My boss then said to me, "there you are, there's your risk management plan".

Initially I didn't understand, but he then clarified it for me - each assumption was simply a risk stated another way.

It also happened to be his agenda for discussing with the client why the project either had to be abandoned or dramatically re-shaped.

We were so well prepared for that conversation that the client agreed fully with us, and agreed to re-shape the project based on de-scoping those parts of the system that were never going to be ready, adding some completion activity to the project to finalise those parts of the system that were close to ready, and re-doing the implementation plan to only cover those parts that were already ready or were close. We had a new scope, a new timeline and a new budget - all of which were achievable.

The client was happy because finally they had an achievable path forward, after many years (yes, years) of trying to implement this system themselves.

We were also happy because we now had a project we could deliver - which we did. On time, on budget and to scope.

By way of example, a classic project assumption is to "assume that the people required to deliver the project are available for their scheduled project tasks". Re-stating that as a risk turns it into "there is a risk that project resources are not available to perform their scheduled project tasks". The classic mitigation for such a risk is to communicate with sufficient notice when people will need to perform their scheduled project tasks so they can block out their diaries accordingly and schedule their other work for other times. Another mitigation is to have the project fund backfill staff to release the project team members to the project. Often you do both.


PM Tip: Ask Another Question

This is another in a series of Project Management tips derived from my experience building an enduring record as a Project Manager who leads business and systems projects from inception to successful completion.

PM Tip: Ask Another Question

Asking questions is one of the primary tools available to you as a project manager - what is the status of this? when will it be complete? what are you waiting on? who are you waiting on? are there any issues I don't know about? what are the risks to successful completion?

I learnt early on my career as a PM that all too often the real answer to such questions is not the first answer you get.

Colin Sander, a colleague in business coaching, who has mentored me regularly over the years, has written on this: Accountability, Closure and Performance: 

[The PM] asked a member of his project team a question relating to the level of progress with a project task.

A simple question: “when will task x be completed?”

The answer from the team member was: “I’m working on it” ...

In this example the response from the PM should have been another question: "that's good to hear, but when will it be completed?"

I happen to know that is exactly what the PM's response was!

And sometimes one more question is not enough.

You need to keep asking further questions until you are fully satisified that you have the full answer.

In my experience it is not that team members are usually being deceptive - if they are you need to hold them to account on that too.

Rather they often perceive such questioning from their PM as a distraction from their work, and will give enough of an answer to make you go away!

If you do go away after receiving an incomplete or even evasive response then you can expect to receive more and more of them.

Ask Another Question!

Prior posts in this series:

  1. Sometimes You Have To Pull An All-Nighter
  2. Look for Early Warning Signs
  3. Intervene Early

11 Leadership Lessons From Jazz Musicians

a good article from Josh Linkner containing 11 Leadership Lessons From Jazz Musicians, which builds on my blog post a few years ago on "Lessons on Leadership from Jazz"

Josh makes 11 points comparing Jazz to Leadership (read the full article for his explanations):

  1. Playing it safe gets you tossed off the stage
  2. There are no do-overs in live performances
  3. Listening to those around you is three times more important than what you play yourself
  4. There's a time to stand out as a soloist and a time to support others and make them shine
  5. Expect surprises and adversity, since jazz (and life) is about how you respond and adapt
  6. Know your audience
  7. It's always better leaving people wanting more, rather than less
  8. The best leaders are those that make others sound good
  9. Pattern recognition is easier than raw genius
  10. Shy musicians are starving artists
  11. Keeping it new and fresh is mandatory



PM Tip: Sometimes You Have To Pull An All-Nighter

This is the third in a series of Project Management tips derived from my experience building an enduring record as a Project Manager who leads business and systems projects from inception to successful completion.

PM Tip: Sometimes You Have To Pull An All-Nighter

As a Project Manager your credibility and integrity is perhaps the most crucial tool you have in your arsenal.

When times get tough on a project - and they will, if it is a project worth committing some of your career to - the ability of your client (the person/s sponsoring your project whether or not they are a client in a traditional sense of being someone you invoice) and your project team to trust you will often be the difference to getting through a challenge, or not.

Recently I committed to produce some critical project planning documents for a project - without factoring that the 4 days after the day I made the promise (a Thursday) were a long planned Friday to Monday family holiday during which I could not work - both in the sense of honouring a commitment to my family, and also I was holidaying in a location without power or internet so literally could not do the work.

The deadline for these documents was the Friday of what had suddenly become a short week for me. Especially as I had another client commitment, which included travel, for the Thursday and Friday of the week the documents were due.

I should have seen it coming, but I didn't. I made a promise I couldn't keep - while working a normal business day.

On the day I made the promise there was more than a week to go. But in reality I only had 2 days of normal business hours to do the work - which wasn't enough.

Maybe I could have reset expectations and pushed out the deadline as I had left myself too short a time to produce these documents - but the commercial reality was they needed to be produced when I had originally promised.

The only way through was for me to 'pull an all-nighter' - which I did.

On the Wednesday evening I worked until 4:30am on the Thursday and got the documents completed. I got to bed for about 1.5 hours then got up to catch my flight to meet the unrelated Thursday and Friday commitment.

I was exhausted - but I had honoured my promise.

The client (whom I subtly made aware of my 'all-nighter'!) now knows that when they receive a commitment from me I will do what it takes to honour my commitments.

And my project team know the same - and won't be surprised when I expect them to do the same.

The influence that flows from keeping my commitments will make me a much more effective project manager.

Sometimes You Have To Pull An All-Nighter!

Prior posts in this series:

  1. Intervene Early
  2. Look for Early Warning Signs

PM Tip: Look for Early Warning Signs

This is the second in a series of Project Management tips derived from my experience building an enduring record as a Project Manager who leads business and systems projects from inception to successful completion.

PM Tip: Look for Early Warning Signs

A few months ago a client went live on a new system for which I was the vendor side project manager.

They were a particularly challenging client throughout the three month project. They were always trying to push project activities back on to the vendor project team - even though they had accepted responsiblity for completing these tasks. This was so they would learn the system during the project so they could be more self-sufficient post-go-live. It was also to keep project costs down.

They were also not very good at managing their diaries. This became a frequent cause of frustration and sometimes delay on the project. We were regularly rescheduling meetings they accepted initially then declined just before the meeting, or simply didn't turn up for.

I had recognised this was probably going to be the case when for the very first project workshop (a whole day) they asked for it to be delayed late on the day before it was scheduled, even though it had been scheduled for weeks, and required travel for a number of workshop attendees (including me). Their excuse - a weekly team meeting within their organisation that they would have known about when scheduling our project workshop many weeks prior.

Apart from being rude we interpreted this as a likely ongoing behaviour, which proved to be the case.

As vendor project manager I became increasingly more active and direct, sometimes blunt, during the project when managing their delivery of their obligations to the project, and even simply turning up to meetings.

The lesson: look for early warning signs. People's behaviour is typically repetitive. If they do something early in a project, they are likely to keep doing it again and again during the project. In this case it was a corporate learned behaviour - the whole client team behaved this way. Sometimes, however, it is one individual who behaves a particular way.

Look for early warning signs!

Prior post in this series:

  1. Intervene Early

PM Tip: Intervene Early

This is the first of what will become a series of Project Management tips derived from my experience building an enduring record as a Project Manager who leads business and systems projects from inception to successful completion.

PM Tip: Intervene Early

One of my current roles is Project Manager for the implementation of a new system at a client organisation which is not accustomed to projects where technology is the primary enabler.

When they were presented with a requirements document, to review for sign off, that was by nature more technical than they are used to, they initially balked and started expressing reservations about their ability to understand the document, much less sign it off.

I have worked for global consulting firms where they would wait until the client didn't sign off the document to raise a formal issue about it - with the excuse that it was clearly pre-agreed that this was the client's responsibility.

But by then it is too late - the milestone has been missed.

Instead, on this occasion, I saw that unless we guided their review of the document they would not get to a position of signing it off. Possibly never, but certainly not within the project timeline.

So we devoted extra time to helping them understand and review the document. They still had to make the judgement calls, but we guided them through the process. More so than usual.

However, by intervening early, helping them understand the document and where they needed to focus their review, the outcome was that they signed off on the document - a day early.

Intervene early!


Jazz is the art of aligning talent so it can perform well

I'm really enjoying getting the regular email newsletter from Brian Fraser of Jazzthink. Overnight this gem - Brian's tip for this month - arrived in my inbox:

Jazz is the art of aligning talent so it can perform well. Musicians discover and develop their own talent through practice - lots of practice - so they can express their genius. They join with others who have done the same to align themselves in playing melodies, rhythms, and harmonies that keep them all in sync and please their audiences. From the core of their genius they align with others to play the core of their common purpose. Exceptional managers and leaders model this process and create an inviting space for it to happen consistently.


For Everyone Who Has Ever Missed A Deadline...

hat tip nathaniel


Jazz and Leadership

Earlier this month I wrote "Lessons on Leadership from Jazz" as the first expression of my thoughts on how "my preferred leadership and working style aligns closely with how jazz music is performed".

This synergy between jazz and leadership is something I had been pondering alone for over a year. Unusually, I had not looked around to see what others were thinking about it. Of course, nothing is new under the sun, and it turns out I am far from the first person to have made the connection!

Within a day of my post appearing Brian Fraser of Jazz Think emailed me (from Canada), and we have since been in conversation by email. I am very encouraged by how rich his thinking is on this topic. I particularly like his 'thought provoker' articles "Innovation, Organisations, and Jazz" and "The Workplace as Jazz Club".

I see Brian has also written a book on the topic, so must purchase it! - even though he also makes it available for free download.


Leading Effective Business Change

Jim Donovan has some good advice on how the project team should be drawn from the best people in the organisation, and on how to lead and generate effective business change generally. His advice is given as '10 rules' (emphasis mine):

1. The project team should be drawn from the best people in the organisation, the ones who will drive the new way, and will likely hold leadership roles in it. Don’t staff projects with your third-rate cast-offs. Don’t rely on contractors for roles that should be held by business experts.
2. The naval officer on site in the dockyard overseeing the construction of a new ship is ideally the officer who will be its first captain. The best person to lead a change project is the person who will run the new process afterwards. Failing that, get someone even more qualified and powerful, not less, to be your change agent. Sitting on a governance committee is not enough.
3. The change leader and the change team must have been indoctrinated into the new way of thinking, and be passionate, effective advocates as well as good at their jobs.
4. Don’t treat change as an IT project, even if largely based around new IT systems. It’s a business project. The best businesses train their business managers in smart project management, process design and change management. These are not IT skills, they are business skills. Having said that, good business-savvy IT people can make great business change people if you also follow rules 1, 2 and 3.
5. Be ambitious but realistic about what you can achieve with the money, time, resources and ownership support you have available to you. Despite knowing this, I too have sometimes fooled myself or been pressured into going ahead on over-ambitious projects without adequate resources, with predictable results. Heroism, hope and luck are not reliable ingredients for success.
6. Give the change leader the power to decide, as far as possible, and have fast access to higher decision-makers when necessary. There is no value-add and much cost from constantly briefing and waiting on uninvolved decision-makers.
7. Like any major change proposal, nothing will happen unless you dedicate resources (people, time, money) to make the change happen. Expecting people to design and implement a major change while doing their day jobs rarely works, especially when their core process is broken. Put your best operational people onto the change project; here’s where you can usefully deploy contractors - to fill in for them in the operational teams.
8. Avoid highly structured project management methodologies. I recommend a much more agile, lo-tech approach. Don’t try to specify everything before you start. Have a high level “architectural” concept to guide you, but get going!
9. Keep the alligators at bay, but focus on the swamp draining. Don’t worry about dealing with the current stream of problems - that’s the job of the operational teams. Put in place some holding plan, but concentrate your best resources on creating the new model that will work. Get it working, put all new customers, and new transactions onto it, transfer all customers without problems onto it, and then, last, not first, deal with the problem backlog.
10. Notwithstanding rule 9, try to deliver value quickly, in chunks, rather than going for the big bang. Incremental success builds support.
11. Bonus rule: communicate, communicate, communicate; up, down, across, inward, outward.

This is great advice Jim, which lines up with my experience as a project manager bringing about business change, often enabled by IT.



Dear Mr Architect

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion.

My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdowns for each configuration so that I can arbitrarily pick one at a later time.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).

As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate (among other things) my 1952 Gibson refrigerator.

To assure that you are building the correct house for our entire family, you will need to contact each of my children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any decisions that you make.

Please don't bother me with small details right now. Your job is to develop the overall plans for the house and get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpeting. However, keep in mind that my wife likes blue.

Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the potential homebuyers in my area that they like the features this house has.

I advise you to run up and look at the house my neighbor build last year, as we like it a great deal. It has many things that we feel we also need in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the construction cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your ideas and completed plans.

PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.

PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case.

Kindest Regards.

received by email, author unknown



I've been thinking a lot about Risk lately.

Increasingly I'm finding the word Risk is more emotive than helpful. This is the case particularly in my professional life, but I'm also finding it holds true in other spheres too.

I'm seeing more and more people, when they hear the word Risk, hear something akin to potential disaster. Events like the recent loss of seven lives in the outdoors simply contribute to this, and it spills into other areas of life too.

Whereas, Risk is simply uncertainty. And Risk Mitigation is simply planning the actions you will take to reduce that uncertainty to an acceptable level.

I'm finding that people understand it quicker if, in Risk discussions, we talk more about moving from uncertainty to certainty.

Professionally I'm currently involved in preparing for four projects - but we simply don't know enough yet to be certain as to the most appropriate approach, how long that might take, and the resources required. In other words there is uncertainty - or risk. None of these projects is potentially going to experience a disaster, but there is uncertainty.

In some cases organisations try to reduce uncertainty by issuing a Request for Proposal (RFP) detailing their requirements. However, my experience is that while RFPs can (sometimes!) be good at articulating functional requirements they are rarely, if ever, good at exposing the true current state, particularly in terms of stakeholder readiness. Accordingly, there is always significant uncertainty as to the appropriate project approach and resourcing required to increase stakeholder readiness to the level required to enable the functional change anticipated.

In the case of the projects I am currently preparing for we are not being subjected to an RFP process. But there is still uncertainty - so we are having to formulate approaches to reduce that uncertainty to a level acceptable to us and our clients.

A typical approach, which we are using in the current cases, is to use an initial scoping and planning phase to increase knowledge of the factors which are currently uncertain - thus reducing uncertainty (risk) to an acceptable level.

The key output of the scoping and planning phase will be the project management plan (project charter) outlining:

  • Scope and Solution
  • Activities, Estimates, Milestones and Deliverables
  • Resources, Project Organisation Structure and Responsibilities
  • Stakeholders and Communication Activity
  • Organisational Alignment Activity
  • Process Alignment Activity
  • Risk Management Plan
  • Assumptions, Constraints and Dependencies
  • Project Processes for Status Reporting, Change Control, Issues and Acceptance

What is your understanding of Risk?