What is a Project

Most people, on hearing the term ‘project’, immediately think of the long, drawn out affairs including large percentages of the company attempting to achieve business-transforming achievements. However if we look at projects based simply on the number and type that occur, we find that a far greater percentage are small affairs with short timespans, small goals, and smaller teams. These smaller projects consume the resources that aren’t on the larger projects, account for the resources from those larger projects when the larger project is not active, and often have little to no natural visibility when viewed beside the game-changing larger project.

Considering there will likely be at least 10 to 20 small projects for each large project, and small projects are less driven to provide high level visibility to a wide audience, it is not strange that the large projects draw attention so naturally.

Stakeholders Have Jobs Too

The Project Stakeholders on a small project generally have something better to do then spend hours in a meeting discussing their small improvement idea. Sure, this small project will allow them to realize a cost savings or remove waste from their processes, but many small projects that enter the IT arena are expected to be fire and forget affairs that require little to no input from the Stakeholders. Calling them stakeholders may even cause spontaneous smiles and laughter, as the people in question will initially think you are exaggerating their role in a purposeful attempt at humor. It may even be difficult to convince them to commit time or energy to the project, as they undoubtedly have many other items demanding their time and, from their viewpoint, this is far too easy to require any additional time from them.

In fact you will likely approach this with the same state of mind. You have had a few conversations, likely informal, with the project Stakeholder and you have enough information to make a first pass. You may even decide to throw some ideas on paper and review them with the Stakeholder at the coffee machine (but more likely your simply drawing in the air with your hands), perhaps fill in a change form or scribble in a clear spot on your whiteboard. This is a small project, you will have it over and done with in less then a few weeks and be on to the next big thing.

And that’s how we fail.

Invisibility as a Form of Failure

We will assume that your product successfully fulfilled the ‘requirements’ you discussed with the ‘Stakeholder’ while waiting for the barely palatable coffee to brew. We will assume that you managed to launch the change on the exact date you originally estimated, with absolutely flawless execution.

How then is this a failure?

First, you measured success purely by getting it done. A week after execution you still have only one measurement of success and six months later your boss is asking what you actually do all day that justifies requests for more assistance, fewer hours, and a better brand of coffee. This is an invisible project. Your net result is one person with slightly higher morale, one more system modification to maintain, and 4 weeks of your life that you will never get back. Congratulations.

Second, speaking of higher morale, all you have achieved in the eyes of the original Stakeholder is a fleeting success, perhaps shaving some time off a process or reducing some other form of waste, but the only part of your effort that will be remembered in a few months is that you are a nice person who finishes what they start. Six months later? Your competent. A year? Isn’t that the guy that did that thing that one time, what was it again?

So your net gain is:

• A little appreciation, soon to fade
• 4 weeks less until vacation
• One to 4 weeks of improvement in the company
• A handwritten reminder to yourself that you did that thing for Joe down the hall

Perhaps if we reduce your pay and vacation time your boss will be able to sell this as netting even when he has to justify your salary (and his) at the end of the year…

Succeeding

Three small steps can turn this whole situation into a positive improvement for the company, your image, your Stakeholder, their image, and (most importantly) everyone’s bosses. Seriously.

• How will this benefit the company?
• How will these benefits be communicated to the company?
• How do we capitalize on those benefits?

Even small projects should have some type of appreciable benefit for the company. Waste reductions, cost reductions, quality improvements, risk reduction: you are executing a project and should be increasing value, otherwise you really shouldn’t be doing that project. Quantify that value and what it costs without this project. You are not simplifying a process, you are:

• Reducing complexity and training requirements by removedSteps/OldNumberOfSteps
• Reducing potential for error – 1/OldNumberOfSteps
• Cycle time – process time reduction
• Task execution time – end-user time reduction

Now you have some numbers, it’s time to determine how you will communicate those results to the company. If you wait until your annual review then your going to get some credit for it, but your boss needs something to take to their annual review, as does the ‘Stakeholder’, their boss, your CEO, … the list goes on. The quantified benefits need to be communicated up the chain, preferably in a way that does not cause your coworkers to make additions to your coffee every time you turn your back.

So back to the conversation you are having with your Stakeholder at the beginning of the project. This time there are a few extra items you are going to discuss, such as a method of reporting the project status and the benefits. This should be a very simple method, both to generate and to understand. Next, while your discussing the potential benefits and the method you will use to report the project status and gains, you are going to extend the project by a couple months.

Yep, read that again. Once more. Ready? We have just taken your small 4 week project and tripled it, it’s going to take have action items stretching over an entire 3 month period. The amount of work has not increased that greatly, in fact if you use the Stakeholder interaction time we have added to the front to prototype the change or draw some quick process diagrams, you may even gain that addition back. The duration increase after the project is there to indicate a post-implementation review of the project and it’s benefits and possibly some time to make up new benefits (we’ll come back to that). Depending on the project you may want to increase or decrease the delay before executing a post-implementation review, but it is essential to come back after implementation and measure the improvements so that you can communicate them. Really, at this point, we only care about the improvements if they are grossly off target (again, we will return to this point), this part of the project is 75% marketing and 25% self improvement. You will have some measurements to communicate upwards and some feedback on how to improve your process, your project skills, your reporting method, etc from your Stakeholder.

As you progress through the year you will begin to accumulate completed projects with quantifiable long-term benefits. After each of the post-implementation meetings you will publish a set of final results as well as projections on what the change will save over the course of a year. This will be provided to the Stakeholder and then, if they are willing, published to a larger group that includes both your boss and theirs. If the savings are significant, bring your boss into the discussion and let them choose whether to take it higher. And finally, make sure that any minions that assisted you with the project receive proper levels of appreciation in the final report.

How do we handle a case where the potential benefits were poorly selected or their estimates grossly off target? Well, we get a bit more learning in that self-improvement to marketing ratio. Spend some time brainstorming what types of improvements you did gain (experience, skill enhancements, process or business model understanding, etc). This is not a high gain report, but you still have some currency if you brainstorm a few ‘secondary benefits’ that were achieved despite the initial benefits not playing out. Not something to take to the CEO, but still marketable and still usable when reporting your progress at the end of the year. Successful execution of a 3 month project on time and on budget with secondary benefits still beats ‘I did that thing for Joe down the hall’.

Details of Success

Lets outline how many ways we just succeeded:

• You (and your stakeholder) just brought measurable long-term savings to the company
• You just managed a small, multi-month project (which will soon become many)
• You just handed your boss something they can take back to their own boss as a success (ditto your stakeholder)
• Longer-term positive appreciation from the Stakeholder because that post-implementation meeting forced them to evaluate the difference in greater detail
• Repeat all of the above for your minions and add in higher morale and extra willingness to work with you on future projects
• Higher levels of Business-IT engagement and the perception that your on the business side of the business/ivory-tower-techie divide
• All of these items are reportable for your year-end review, your bosses year-end review, your Stakeholder’s year-end review…

Or if we go back to the beginning we could spend 4-8 hours less and simply complete the project, one more easily ignored item when we share our tasks in the staff meeting.