A basic map of our stakeholders
Quite some time ago, I wrote an article on “creating a basic communication plan” and for many projects that is all you need.
But sometimes it is worth analysing your stakeholders in more detail. This article explores a couple of approaches that I like to use when I need to understand more about my end users or more about my “project stakeholders”.
Continue reading “Analysing stakeholders – beyond the basic communication plan”
Not many people seem to know what an affinity diagram is, but most project teams seem to have used them. So maybe I am using the wrong term for the process of “writing ideas on a post-it note and then whacking them up on a wall”.
In my defence though, most seem to have mixed experiences with workshops where they put all their ideas up on a wall. It seems that many workshops involve people brainstorming (or “brain-writing”) ideas on post-it notes and then all putting them up on a wall – but then the workshop ends. The facilitator says something like “thanks – now we will take all this away and get back to you” and the rest of the crew wonder what is going on.
So this article describes a process that can be applied to apply a useful structure to “putting ideas up on the wall”. I will be using the fictional BA team that I have used in a couple of recent posts and I will see if we can help them solve their problem
Continue reading “Collaborative problem solving with affinity diagrams”
In my last article, I described an approach that you can use to define the purpose of an internal consulting team.
I used Sophie and her BA team as an example and I will continue to do so here. This time I will talk about the “Service catalogue” or list of services that your team provides to stakeholders in the business.
Our approach at a high level
Sophie and her managers have just defined what their team’s purpose is, so it should be easy to create a list of the services that be needed to achieve that purpose. But in reality, a lot of the work done by internal teams is “as per the stakeholder’s request” and not at all aligned to the team’s alleged reason for existence. So we will attack this problem from two angles
- What Sophie and her managers think the team should be doing; and
- What the team are actually doing at the moment.
We will then look at the gap and work out what to do about it.
Sorry, but it turns out to be a long article, so pour a cup of tea for yourself or just read one heading at a time.
Continue reading “Defining the value of your internal consulting team part 2 – your services”
Like every other cool project manager these days I like to be agile. But I used to be a pretty good waterfall project manager before I found out how uncool it was.
One of the common things I used to do was called “crashing the project schedule”. In fact it is probably the most fun part of project management.
But one problem that always seemed to catch me out was the Race Condition (or Race Hazard). If you look it up in wikipedia then you will find it happens to electrical circuits, but I have found it also happens to all my project plans that involve more thabn half a dozen people or more than a month long planning horizon.
Continue reading “Who knew the race condition (or racetrack problem) could blow up your project schedule?”
I often seem to face the same problem – how can I reduce my resources, increase my scope, improve quality and go faster?
The best answer is – be clear on what you really want and decrease your scope. Sadly that is the opposite of what people want to hear, but usually delivering the right thing (done well) is better than delivering a lot (even if its done well).
But I have also found that the grinding task of trying to fit more in and failing can actually help you define what you really need. So I often find the process worthwhile even though I end up with a different scope rather than a bigger one. So here are some ideas I have tried:
Continue reading “Can I add more scope and still deliver on time? Or should I Scamper”
Niccolò Machiavelli is famous for saying things like:
“At this point one may note that men must be either pampered or annihilated. They avenge light offenses; they cannot avenge severe ones; hence, the harm one does to a man must be such as to obviate any fear of revenge”
I will let you be the judge of whether that is good advice for project managers, but he is certainly a source of inspiration if you want to set up your own crime gang or evil crew of super-heroes.
However, I do think some of the things that Machiavelli commented on are useful in modern projects.
One of his lesser know observations was on the difference between “Dukes and Courtiers”.
- Each Prince, Machiavelli noted, is likely to have a bunch of Dukes and Courtiers reporting to him and these two roles are distinctly different.
- Dukes run their own mini-fiefdom on behalf of the prince. They make many day-to-day decisions and are in most ways mini-princes. In fact the duke will do well if he (or she I guess these days) sends in lots of taxes to the prince and generally maintains good order (and its probably best not to rebel or attack the Prince).
- Courtiers hang out in the palace and join committees and according to the movies I have seen, they chat girls up and indulge in lots of politics. But they also provide direct advice to the prince and also work with him to run the complex day to day matters of the kingdom or principality. As far as I can tell they should be (less evil) versions or the characters in the TV series “The Tudors”.
So Machiavelli is probably a good source of inspiration for period pieces, but how does it apply to going live with an agile project?
Continue reading “Going live on agile projects – where is Machiavelli when you need him?”
When I first learned project management we were really into waterfall concepts like crashing the schedule and EVA. In fact I really enjoyed the process of Pert charts and planning.
But I stated to notice that many difficult things ended up being deferred to “release 2” then “release 2.1” and then “post-release business as usual”. This actually meant they didn’t get done. So I was talking to an experienced PM from a consultancy and he introduced me to the concept of “the peak of expectation and the trough of disappointment”.
Continue reading “Updating the trough of despair – Do projects always double dip?”
In the past I have used some pretty dodgy approaches to defining risks in a project, from formal approaches like fault tree analysis through to informal approaches like “the evil genius” and “an international standard for being scared“.
So this article is not really a new one. It is more a combination of evil geniuses and international standards for being scared. But I think this workshop should work well when starting any project and particularly small projects with a simple project charter.
Continue reading “A prophets of doom workshop”
I have previously blogged about a number of approaches to assessing a team’s readiness for change, including the 7-S framework and the arenas of change approach, but today I thought I would explain a less well known approach – the “moments of truth” assessment.
Actually I made it up so it is not too well understood outside of my own loungeroom. The approach is essentially the same as the 7-S style of assessing the interaction of the multiple systems, skills, stucture and other elements of the team’s whole ecosystem. But this is a little different because we start by looking at when (and why) the team’s internal or external customers interact with it. Then we assess the team’s ability to support those interactions.
Moment of truth(n) a moment when a person or thing is put to the test
Collins English Dictionary as quoted at http://www.thefreedictionary.com
Any interaction with a client is “a moment of truth” for the team. It tests the connection between the team’s value proposition, strategy, implementation, staff, skills and systems and it generates the experience that lasts in the customer’s memory until he or she interacts with the team again.
A “moments of truth analysis” therefore starts by identifying the interactions a team has with its customers, stakeholders and potentially vendors.
Continue reading “Using a moments of truth analysis to assess a team’s readiness for change”
Every retrospective I do on every project seems to include the conclusion that “we need less meetings, less emails and more communication”.
In fact SCRUM and agile approaches even try to define the bare minimum number of meetings that are needed and only have them (Actually one of my friends claims that they have removed all the meetings – “In agile we don’t have meetings, we only have workshops. Meetings are discussions and Workshops produce something tangible each time”).
Yet the reality seems to remain that meetings (or workshops, or gatherings, or war councils) often end up getting in the way of doing the real work:
So what would you do if you had to look at the return on investment of each meeting? Would they actually stack up from the point of view of making money for shareholders, making life easier for the crew or improving the experience for our customers?
Continue reading “What if people thought meetings were actually work?”