The paradox of small projects

Late last year I was asked to help deliver a ‘small’ project. My workload was fairly loaded so before I agreed, I checked the scope had a quick discussion with the selected implementation partner to assess what was required. It seemed like a quick and easy project, so I agreed to be the project manager. 12 months later, is this really a small project?

On reflection, here is what went wrong.

• I perceived the project to be small based on limited information / analysis
• With the project only expected to last three to four months, I trimmed down my project management activities like abbreviating the stakeholder analysis process, gaining organisational change management input, and benefits management process
• I viewed my involvement as part-time
• Last and potentially the worst, I assumed that the organisation understood and wanted the project (I based this assumption on the fact that a team of people across each department had come up with the project concept, a team member had prepared a business case, and the Senior Management Team had approved the business case).

How did these ‘wrongs’ manifest themselves during the project:

• While we defined the potential business value, we did not have a clear or detailed plan of how we would realise this benefit.
• The project team showed signs of stress as project work chewed up operational time, and additional but necessary tasks were treated with dread.
• The team that would own the project deliverables at project completion continually challenged the value of the project.

What would I do next time?

• Spend more time on understanding, documenting, and agreeing benefits and the process for their realisation.
• Complete a full stakeholder analysis supported but a full communications plan and change management plan.
• Plan with the end in mind; for example, define and agree who will be the operational owners of the project deliverables and ensure that they understand the value for the organisation and to them personally.

I am interested in your thoughts on managing small projects particularly when you have other larger project on the go at the same time.

Operational cost approval in business cases

Hindsight is easy. I have been writing business cases for years and have just realised a fatal error. What happens where the person responsible for an ongoing operational cost for a project deliverable is not part of the business case process?

In most cases this doesn’t happen but I have just completed a project where our procurement and finance departments initiated a project, where one of the ongoing operational costs is an information systems cost. Long story short, the information systems team do not want to pay these ongiong costs as they have not budgeted for them.

I hope there aren’t too many others in this position, as it’s an embarassing one!

I have now updated our business case template to add a budget owner column for the ongoing operational costs, and added operational cost owners to the approval page.

Three strikes and you’re out

Have you ever been working on a project and there is a recurring issue with a deliverable. You discuss the issue with the people involved – nothing happens, you discuss the issue with the project sponsor – nothing happens, you discuss the issue with the steering group – nothing happens. Well guess what, you probably do not need that deliverable. If the deliverable were important, it would have been completed a long time ago.

Something I heard a long time ago, was that if something is delayed twice drop it. I would expand this to give the project sponsor one final change to justify the deliverable. That is, the sponsor must present a compelling case why the deliverable is still required and then provide significant reassurance that he will support the completion of the deliverable. This expands the two strike rule to a three strikes and you’re out.

Follow the three strikes and you are out rule to stop wasting time in your projects riding dead horses, and to ensure that you are focused on the priority deliverables.

Weekly communications plan

In projects we generally use some form of communications plan to address stakeholder needs throughout the project. Something that I have been thinking about more and more is the need for a project manager to spend dedicated time communicating each week. That is, to allocate / plan time for specific communication tasks each week.

Previously, I communicated when I needed to. What this meant is that I relied on people to keep their word and complete the required work to the agreed quality, cost, time etc. It also meant that I relied on the sponsor and steering group supporting and promoting it as appropriate through their normal course of work.

Reality was quite different.

Starting this week, I reviewed the project schedule first thing Monday morning, and created a personal communications plan to cover off the key stakeholders for the week, key messages / questions, mode of communication, and timing. I then blocked out time in my calendar for dedicated communication activities.

I am at the end of the week today, and everything fell into place nicely. All work activities were completed as scheduled, the team and key stakeholders are up with the play, and I feel relaxed after what should have been a hectic week.

Improvements? Reflecting on the week, I would allocate more time to communication each week and potentially plan further in advance. Not sure how much in advance I could / should plan though as I already have booked team, sponsor, and steering group meetings scheduled for four months in advance.

In summary, book in time for communication each week – it is worth it on many levels: work gets done, the team and key stakeholders feel more connected, and your stress levels drop several metres.

Lippitt’s phases of change theory

I have just finished a project that had a significant organisational change management component. In short, things did not go so well.

I have started learning more about change management and over the coming posts will summarise, very briefly, learning that I feel is suitable for projects that have a significant organisational change management component. To start with here is my take on Lippitt’s phases of change theory

Lippitt, Watson, and Westley (1958) propose a seven-step theory that focuses on the role of the change agent throughout the evolution of the change. The seven steps are:

1. Diagnose the problem
2. Assess the motivation and capacity for change
3. Assess the resources and motivation of the change agent. This includes the change agent’s commitment to change, power, and stamina.
4. Define progressive stages of change
5. Ensure the roles and responsibilities of changes agents are clear and understood. Examples of roles include the motivator, facilitator, and subject matter expert
6. Maintain the change through communication, feedback, and group coordination.
7. Gradually remove the change agents from relationship, as the change becomes part of the organisational culture.

I like this theory from a project perspective because it gives you a larger and more effective voice within the organisation; that is, you have key players within the organisation driving and supporting the change as opposed to those ‘project people’ trying to get us to do things differently when we are happy with the way we do things now. This is also an empowering process for the change agents.

To be successful you must be confident that organisation has the motivation and capacity for change and you must have the ‘right’ change agents.

We often assume the motivation and capacity for change and strangely, senior management often make this assumption when they can be most change resistant.

You will often know who the ‘right’ change agents are. Securing them for your project can be a completely new ball game. At a minimum, you must obtain buy-in from the change agent, formal approval from their manager, and a plan to manage project versus operational time including integration back into the organisation at the completion of the project.

I am interested to hear if anyone has successfully used Lippitt’s phases of change theory in a project.

Project team member accountability

Okay, so you are a project manager. This means that you rely on achieving outcomes through others. Some project managers including me at times, have slipped into the dark hole of stepping in to be the knight in shining armour to complete a piece of work, and save the day. This is the wrong thing to do on so many fronts.

Let us talk about accountability – if you save the day once the expectation is that you will always be there to save the day and the people on your project team do not really need to do the work for which they are responsible.

It grates me to no end when we go through a planning session and we come to an agreement with project team members that they will complete a piece of work within a set timeframe. With some team members a pattern forms over time – not only do they miss the delivery date, they do not let any one know about this. Sometimes they do not even start the piece of work before the due date.

Some could say that it is the role of the project manager to follow up with all project team members to make sure that they know what they need to do and to ensure that they are on track (or not) with delivery. In small teams, this is possible although I am not sure how this works when you are working on team that are greater than 30 in size. Also, what ever happened to personal responsibility and accountability?

So what to do? I have three initial thoughts:

• Planning: Send more time planning tasks so that project team members better understand their work both in the context of the project and in relation to their ‘business as usual’ demands.
• Communication: Allocate more time each week to talk with project team members that are due to complete deliverables within the next two weeks.
• Visibility: Record and publish project team member performance; that is, make it visible for the project and the relevant managers who is performing and who is not. I am not sure how to ‘publish’ this information for the appropriate people to see just yet, but I am working on it.

Let me know if you have done anything similar or have alternate approaches to ensure accountability.

Program and portfolio management: Getting to the next level

Late 2006, Gartner put out a paper with the above title. While it is old and brief, there are some good points that remain valid. In particular, the comments on evolving the PMO.

Evolving the PMO covered five points – the two I found most relevant were:

Expanding the PMO’s involvement in the area of business case development

• Involvement in business case development is critical to ensure a common understanding of project objectives among the primary stakeholders (including the project manager).
• Expectations of business outcomes are also set with senior management at the business case stage. For a project manager this is a big deal if you come in to deliver a project with unrealistic or ‘foggy’ outcomes. I have been in this situation and it was extremely difficult to get the senior management team to back track to reassess the validity of the expected business outcomes. First in best dressed work in project management too.

Expanding the PMO’s involvement in the area of organisational project management

• Projects generally require people change. Unless you build this in as part of the project, ultimately you will fail. The days are gone where you supply a set of project deliverables and you are done.
• The business will judge your success on achieving the actual business outcomes and related value.
• At a minimum, you need to identify the areas of change required, help the organisation communicate and manage change, and assess how successful the organisation has been in embracing the change.

Finally, PMO’s should ideally operate at an enterprise level not within IT or similar silos. At an enterprise level PMO’s have a better chance of providing and ensuring a consistent set of portfolio, program, and project processes, controls, and measures of performance to ensure the success of all business initiatives.

Gartner hype cycle for emerging technologies

I picked up this from a recent Gartner press release. It is a great illustration of where Gartner see technology sitting and where they expect it to go. A couple of things caught my attention:

When should you get into a particular technology? For example, Apple is getting into Green IT with their current work on Snow Leopard. Why get into this now considering its place on the peak of inflated expectations? Is this a play on market expectations?

Web 2.0 sadly sits in the trough of disillusionment although it is close to mainstream adoption, which suggests that this will move quickly through the slope of enlightenment and into the plateau of productivity. I cannot wait for more NZ organisations to pick up and run with the web 2.0 movement. I seem to fight a never-ending battle on this in my work environments.

Good to see corporate blogging, idea management, and wiki’s moving up the slope of enlightenment. In my current organisation knowledge and expertise is locked away in silo’s at it would be great for GMs, managers, and subject matter experts to spread their knowledge.

I am encouraged by the direction and expected timing of emerging technologies. I only hope that this is not a US view and that we in NZ are another two to five years behind this.

Planning a project with multiple / discrete work streams

Over the week, I have been pulling together a project management plan for a back office integration project that has six discrete work streams. I ran six separate planning workshops throughout the week that covered off:

• Expected business outcomes
• Deliverables
• Responsibilities
• Key dates and timing constraints
• Risk

The things that worked well were:

• Keep it short: One hour sessions worked well for me
• Automate note taking: Use a printable whiteboard – great for brainstorming, making changes, and capturing notes
• Small groups: Work with small groups of no more than six people. Also make sure that you have the ‘right’ people in the room; that is, people that know and understand the expected business change / outcome
• Keep it at the right level: Only go down to the level of deliverables – work requirements are too much detail for the workshop and causes people to disconnect.
• Assign responsibility: Assigning a single person as responsible for each deliverable starts the process of accountability and provides an out for following up work and resource requirements for each deliverable as an action item

Things I would do different next time:

• Consider using pre-loaded content: I am in two minds on this as it may prevent ‘fresh storming’ and lead to confined brainstorming
• Have more control over discussions that focus on making decisions / doing the work of the project. This needs to be weighed up against constructive group discussion that leads to a better understanding of the project requirements.
• Provide a better description of the differences between business outcomes, deliverables, and work. I get the differences because I have been through this process hundreds of times but for many participants this is their first time in a meeting of this sort.
• Keep myself fresh: By the end of the third session going through the same process repeatedly, I started to get a bit flat on it all. Not sure what to do here but I need to keep the energy up somehow as my energy supports the energy of the process.

All in all a good process and I have a good start to my project management plan. I have the schedule, governance, communications, and financials to sort early next week. All going well I should have the first full version of the plan ready for review by the end of next week.

Evaluating projects from a value perspective

I am setting up a value framework and I have weekly musings over how to best identify, plan, and measure value. Then there is the implementation…

Here are some current thoughts on the topic…

When we assess the value of a project, we currently focus solely on the financial benefits that we expect to receive from this investment. There are a number of issues with this approach including:

• Assumptions: All NPV and IRR type calculations are based on a set of assumptions, which leads to widely varying ‘values’. The presentation of assumptions is also often incomplete or ambiguous.
• Precision: Single figure values (as a result of a NPV type calculation) imply a precision that sets unrealistic expectations.
• Intangibles: These calculations do not account for intangibles like customer or employee satisfaction – these go in the too hard basket.
• Risk: These value calculations do not include the risk profile of the investment or comparative results from similar projects; for example, if we often blow the budget by 20% on these types of projects should we elevate the expected cost to deliver this project?

Intel has created a Business Value Index that looks to resolve some these issues. It is IT focused but you can expand it to cover ‘business’ projects by combining it with Forrester’s Total Economic Impact methodology to include risk (I prefer to drop flexibility and IT efficiency to make things generic). Using this hybrid approach, you would consider three value components:

• Business value: Covers tangible and intangible benefits using a set of weighted criteria to cover things like customer need, strategic alignment, revenue potential, etc. The idea is to focus on value elements specific to your organisation.
• Financial attractiveness: NVP, IRR, payback period calculations.
• Risk: Review the initial estimates for cost and benefit based on the project risk profile. In doing this you create a risk-adjusted costs and benefits.

You can present this information visually using three axis in an investment cube using three columns / rows for each axis (-ve, neutral, +ve; or low, medium, high). Presenting the information in this way, enables you to easily compare competing projects.

The goal here is to use a consistent approach for evaluating projects based on facts and within an apples versus apples environment. To be effective the ‘facts’ should include information on strategic alignment, expected value, and risk.