Recently people at work have been asking my advice on how to run post implementation reviews of major programmes so I thought I’d write up my thoughts. I believe there are two types of post implementation review and I recommend doing both. The first type happens in Project Closure and the second happens after the project has finished, i.e. Post Project.
Continue reading
Managers v Leaders: Are Managers Plodders and Leaders Cool?
I consider myself a good manager and a passable leader. This should be okay but there is a certain anti-manager trend in the business world that is particularly prevalent in the Agile community. For example it has been common for Agilists to say "We don’t need no stinking managers " (Esther Derby: Rethinking Managers Relationship with Agile Teams).
It seems that leaders are somehow more cool than managers. Conventional wisdom says "Managers do things right; Leaders do the right things" (Buckingham & Coffman, 2001). And Jim Highsmith (2009), one of the Agile gurus, makes it clear that Leader = Agile and Manager = Non-Agile. Ouch.
Agile leaders lead teams, non-agile ones manage tasks.
Highsmith (2009) cited by Scrum Expert
All of which makes self-labelling as a "manager", particularly an "Agile manager", rather risky. But before I go off to find a job as a leader, for which I’m possibly under qualified, I thought I’d take a look at the differences between leaders and managers and assess whether common wisdom is, after all, very wise at all. To do that I’ll outline what a couple of other people say about managers and leaders and how that marries up with my own view.
Continue reading
Foot in the Door Technique
My four year old daughter is an master social psychologist, or just a natural manipulator. Here’s an example:
Daughter: Can I go over to Lilia’s house to play?
Dad: Sure
… some time latter …
Daughter: Can I stay for a sleep over?
Dad: Um, I guess so.
My daughter doesn’t know it but she is using what social psychologists call the "foot-in-the-door" technique (Brehm & Kassin, 1993). The same technique is applicable when rolling out new software.
Continue reading
Declaration of Interdependence
In 2004 some people met to define what agile project management should mean. In February 2005 they published a statement called the “Declaration of Interdependence” (DOI). According to David Anderson (Kanban and the DOI), one of the signatories, the intent was to:
- define a value system by which modern 21st Century project managers should live and
- galvanise a community around general application of agile project management
Putting all your eggs in one basket
A common English phrase is:
Don’t put all your eggs in one basket
English proverb
This is sensible advice and is really suggesting a risk mitigation strategy (see Risk Management). The proverb, fairly obviously, means don’t put all your resources (money, time, energy) into the same activity, just in case that activity fails. Or, put another way, avoid single points of failure. Or, to use another common phrase, keeping your options open.
This advice applies in many situations and at many levels. For example:
- Royal succession
- Personal investments
- Infrastructure
- Portfolio management
- Programme or Project contingency
- Technical design
The Royals apply this advice in their efforts to have an "heir and a spare" to ensure succession.
At a more mundane level a sensible share portfolio has diverse investments to reduce the risk of failure of any one.
As my main interest is programmes, portfolios and projects I’ll concentrate on the last examples.
Continue reading
Migrated site and blog to WordPress
Aside
I have moved the website and blog from Joomla to WordPress. WordPress is simpler, with a cleaner user interface, yet has better functionality out-of-the-box. Apologies if anybody has any bookmarks which are now broken.
Simon’s Critical Success Factors for a Software Release
I was on leave for a week and when I got back I found a new flip chart was on the wall.
Critical Success Factors when we release:
- Functionality – Does it do the job?
- Usability – Does it do it well?
- Performance – Does it do it fast?
- Evolution – Does it build smoothly on what is already there?
- Delivery – Is it ready on time?
- Comms / Training – Have we told people about it?
Change is Good for Agile Projects
Kelley Hunsberger interviewed me for her article “Change is Good: For agile projects, redefining scope isn’t such a creepy thing”. It is great to see agile thinking in a mainstream project management magazine such as PM Network. And the article was a very nice little summary of why it is good to embrace change.
I took the opportunity to reiterate some of the points I’ve already made on Agile Project Scope and Agile Change Management, namely that all projects experience changing requirements and it is better to embrace this than fight it. For example legitimate sources of change include:
- The customer learns as they see working functionality emerging of the development effort.
- The technical team is also learning as they discover what works.
- The environmental context might also dictate changes, such as changes in the market or legislation.
Ignoring any of these sources of “scope creep” would be foolish.
Continue reading
Programme versus Project Risks
Today a new project manager, somebody running one of my work streams, asked to put her risks on my programme risk and issues log. She didn’t really want to but apparently she’d been told to do this by her organisational masters outside the programme. I told her not to. Why? Because I use the log for the programme not the sub-projects. Since I had to explain my thinking to people in the company I thought it warranted a blog entry.
Continue reading
Build it in a Week
I ran a massed prototyping exercise with my current team. The whole team: development, user experience and design, testing, product management, business analysis, programme/project management and the programme director. It was a concerted effort to get a solution covering everything. The idea was to build wide not deep. The requirements for the end to end workflow was a generic operating model we’d developed previously. Microsoft Sharepoint was the underlying platform so this exercise concentrated on “out-of-the-box” solutions based on Sharepoint.
Expected Benefits
I allocated a week for this so the cost was quite high. On the other hand I expected considerable benefits. I expected “Build it in a Week” to enable us to:
- understand the requirements more
- validate the generic operating model
- validate the emerging information architecture
- identify technical challenges and identify if “tricky” things were in fact simple
- demo an end to end solution (even if clunky and with caveats)
- understand Sharepoint 2010 more, specifically understand what “out-of-the-box” means in 2010
- identify what we can’t do “out-of-the-box” right now
- understand each other more
As programme manager I thought it worth the cost.
Continue reading