Successful Project Management

The Secrets of Successful Project Management

• a clear and tested view of what you’re trying to achieve
• a simple but consistent approach
• good technical people
• good business people
• time and budget
• management sponsorship
• the wisdom of experience
• to keep the overview and never take your eye off the ball
• to care

And speaking of the wisdom of experience, here are some nuggets from our 30 years in the charity sector:

Little jumps vs Giant leaps

Changing systems is disruptive. If there is a lot of change coming, it’s tempting to batch it all up into one big heave to minimize the disruption.

Don’t do it. Any new software means a leap into the unknown and some risk that it will not fit. A phased approach with three small jumps is more predictable than one giant leap into the unknown. More predictable means less risky, more likely to succeed.

With small jumps you can pause & trim between them, reflect the light of experience, reality, changing circumstances...

With a 'great leap forward', once you jump you've bet the farm. Likelihood is it won't be that great, it may not even be forward (ask Deng Xiaoping)... it's 'get rich quick'; it's do-or-die; it's the embodiment of desperation.. don’t do it!

Small leaps work

The bigger the change the more removed you’ll be from your current normal operations, so the more you’ll have to guess the real requirement. The more you guess, the more danger of getting it wrong.

The bigger the system, the more it feels like it’s being foisted on users.

The bigger the system, the longer it takes to build, the more tired everyone gets, and the more it costs!

If you can keep things as small as possible, whilst still meeting the key requirements, there’s more chance users will accept the new system and come back asking for more.

These things are really hard to pull off successfully, so don't go out in a blaze of glory; burn your fingers on a small fire - learn how it works... that's how to succeed.

Think three years

This sector (in our experience) spends 3-7% of turnover on IT and ½ to 2% on information systems and web sites. If your project takes you outside this range, you may be special. Or you may be headed for a funding cut in year two.

We often dig deep for big IT projects, then find we can’t sustain the investment. Bespoke software projects are particularly vulnerable: if you cut spending after year one, the organization moves on but the system doesn’t, and it will soon become irrelevant and fall into disuse. Make your first budget a three year budget.

How much should we budget for phase two?

Our rule of thumb is to expect a phase of roughly 50% the size of phase one within three months to two years of go-live.

Informal ITTs

Invitations to Tender (ITTs) are dull and impersonal for everyone, so cover all areas but be brief.

Take inputs from a number of people, but don’t just cobble the document together, as that can make it incoherent and therefore difficult for suppliers to understand and share your vision and set out the best solution.

ITT’s are necessary, but if you want the best solution you should meet the suppliers too. The more open you are, the better the tenders you get back.

Simple Project Management

Complex projects attract complex management methodologies, with their own elaborate rules and jargon - they can get in the way, they can hide problems.

Keep it simple, and stay on top of it.

At any point you must have:

• an up-to-date summary level plan and budget – what’s done and what remains to be done
• the current allocation of roles

It’s one thing to have a plan, it’s another to police it - don’t let the project move past a milestone until you are satisfied with the work. Don’t pay until you’re happy.

IT manager vs Business Manager

We often think, “New XYZ system, obviously a job for the IT manager”.  But the IT manager has no idea what XYZ is. Get the IT manager to help, but make the XYZ business manager the boss – they know the domain and they are the main beneficiary.

Why do we need to draw the system on paper when we already know what we want? Bet you don’t

For sure, everyone has a vague notion of the system, but when it comes to the detail, the reality of how this application will really be used, how it will hang together, how the new bits will interact, what happens if nobody does this or someone does that at the same time …

Nobody really knows what they want

...until they’ve had it for six months, and by then most of the money has been spent and you're stuck with it. Imagine your new kitchen, you can have exactly what you want! You design it; it's built; you use it, and... six months later: "I wish we'd put the fridge next to the... / made it easier to sit at the breakfast bar... / not bothered with that useless extractor hood..." It's the same with information systems, and if you don’t put adequate quality time into modelling what you want, you know full-well you’ll get a system that isn’t what you want. PaperBuilding won't produce perfection but it is a guarantee that a group of people have put best efforts into modelling what they want and kicking it till it stops moving – they do know what they want, they have thought the thing through, and they are confident it makes sense.

Everything is built twice...

… once conceptually, and once physically. The PaperBuild is the conceptual stage. And if you miss it you end up having to repeat the physical stage, i.e. you build twice, and pay for it twice, and that’s once too much.

We don’t understand each other...

Take the word ‘project’ – nearly every organisation has them, but they seem to have a different meaning in each. Even in the same organisation, even in the same job, we carry round different meanings for jargon terms.  PaperBuilding spits this out into pictures and simple definitions. It allows members of the same organisation to ask the crucial ‘stupid questions’ that reveal the common misunderstandings and make for a coherent system.

“No time to talk, no time to PaperBuild, got to press on!”

We sometimes come across organisations who have no time to explain what they want. They expect to be able to say a few words and for their software providers to infer from that everything that’s in their heads. It’s the best way to guarantee a bad outcome.

Time works

Part of the PaperBuilding idea is to split the exercise up into a series of sessions one week apart. When you leave a session, some of the ideas will stay with you and rattle around in your head, maturing, leading to a more fully baked expression at the next session.

When you come to sessions separated by a week, you’re in a different frame of mind, you bring a slightly different perspective. This helps give the PaperBuild a more rounded aspect.

Computers slow things down

Pencils and paper in this day and age! Why don’t you do it on computers? If members of the group have sight or hearing impairment, or the group is spread around the country then computers can be the answer.

Otherwise, computers tend to lead to one person inputting and everyone else watching – they disenfranchise the group. If everyone has a pencil and paper and a specific job then everyone has to engage and be part of the team. As the workshops progress, the participants take ownership and gain a deeper understanding of the project. They become advocates of the project. It’s also more fun!

And anyway, we always do shift the PaperBuild into HTML (see PaperBuildDB) once it’s complete. But paper is still best for creating the initial requirement definition.

Curse of the Leaver

“When I took this job I promised to implement a new XYZ system. I’m leaving in five months, but if it’s the last thing I do I will implement that new system.”

And yes, they’re guaranteed to leave it unfinished, and leave their replacement (if there is one!) with something they wouldn’t have asked for, and don’t want … the curse of the leaver is almost certain failure.

Projects that need fundraising

Q. How much will it cost to implement a CRM system for case management?

A. Easy - £X.

A bid then goes in for a budget of £X, and everyone starts dreaming about the new system and coming up with ideas for it.

Three years later the budget of 90% of £X comes through - hooray!

But in the meantime the requirement has become: an organisation-wide CRM with event, case and xyz management, fully integrated with the accounting system and the CMS – which will cost £2X and so we can’t do it – boo!

Moral: for projects that need fundraising, allow for three years of scope creep.

Your time vs PM time

We’re often asked by clients how much time the project manager should set aside, is it a temporary full time post?

In our experience, generally around 20-25% of our time on a project implementation is needed for project management. For us, this typically means half a day per week during active stages.

We recommend that the client organisation’s project manager (the CPM) budgets the same amount of time as our project manager.

Testing deadlines – cruel to be kind

If you ask someone to test a piece of software and give them no deadline, 60% of people just won’t test it.

If you set a deadline of three weeks, most people will leave it for two weeks and four days, forget what it was all about, and do a half-hearted effort on the final day before the deadline. It’s a kind of testing but it’s poor, not what we want.

If you give someone one week to do a test, they usually say, "Well, I might as well do it today/tomorrow while it’s fresh in my mind."  If that happens we get good, meaningful testing.

Our standard testing deadline is five working days.

Why should I test it?

“I’m really busy so I’ll get the student placement to do some testing, or we could get the suppliers to do it!”

Of course, Infoworks as a supplier does test everything before it comes before your project manager – it will be tested by the developer and the Infoworks PM.

But they’re not you - they don’t understand your business as you do, and they may subconsciously will it to pass.  Your CPM is the frontline stakeholder – they are by far the best tester.

Don’t lose the users

Finally, and most important, if you keep your users involved throughout, it’s hard to go too far wrong.

Build their involvement into every step of the plan. Take their initial inputs, their design thinking. Get them to own it, get them to test every deliverable.

If you ignore them at any point you may miss the target and risk rejection – lose the users, and you really have lost the system.