The Money Files

Don't you just hate change control?  According to a study by Jama Software, 75% of project managers are managing projects with at least 100 requirements.  One in five are managing projects with over 1,000 requirements.  That's a big project.  Here's a summary of the rest of their findings:

Download the full report here.

Jeff Furman, PMP and author of The Project Management Answer Book, has lots of experience running change management processes. And we all know that early changes are cheaper than changes at the last minute. I talked to Jeff about his experiences and what we should all be doing when it comes to good change management.

Hello Jeff.  You used to run a large change management system. Can you tell me a bit about that?

Hi Elizabeth, yes, I worked for a brokerage firm in Manhattan with an IT department of more than 1,000 developers (including a wing in London!)  Brokerage people will all tell you there is a “life and death” urgency when putting in any software change in their environment, because the traders often need to  take advantage of the new code ASAP to process their trades accurately (especially when the changes involve new laws or regulations!)  Our company chose a vendor change management solution which could handle the diverse programming needs of hundreds of projects simultaneously, 24x7, and I managed the team that supported and customized this system through several successful upgrades.  

That sounds like a complex system, but one that worked really well. Why was the system so good?

A good IT change management system must be user-friendly, as well as customizable and flexible, meaning it can support many types of software changes.  But of paramount importance in a financial environment, it also must be VERY SAFE!  To that end, our system included a very powerful “automated back-out capability,” meaning that if a bug was discovered after a change went in, all components associated with the developer’s change package could be backed out in one shot, and automatically replaced by the previous versions. This meant that if a developer got a call at 3:00 am EST to pull a change package containing 50 components before trading opened in London the next morning (where it was already 8:00 am) he or she wouldn’t have to scramble to find the 50 prior versions -- the system did that for them.

Was there anything you would do differently if you worked on something like that again?

Two things –

1.  Earlier training– What really got people to embrace the system was a customized training program we put together, highlighting the benefits to the developers.  If I had a time machine, I would go back and initiate this training even sooner, because as you say about social media tools in your book, “If they can see the benefits, they will use the tool.”  There was ironically resistance to change to the change management system, and it didn’t catch on until the training.    

2.  Customizations with future vendor upgrades in mind -- We had a very large customer-base, and so there were a great many enhancement requests over the years.  Beware that the more you customize your system, the more it will take to maintain it over future upgrades, which often need to be done fast.  If I could take a second ride on the time-machine, I would push back harder against some of the customizations we agreed to.

What are your tips for good change management?

Stay strong about change approval rights: PMs often tell me they work with systems where people can bypass their process.  This undercuts the system and in some cases the success of their projects.  A tip for avoiding this problem is to get advance agreement from senior stakeholders that changes will go in ONLY if they are authorized by the designated approvers.  This works because it puts them on record for agreeing this is for the greater good of the company, which also gives them buy-in to the rules being enforced.

Customer-focused training: Bring in a good class early, customize it to your environment, and emphasize the biggest benefits to the people who will be using it.

Don’t reinvent this particular wheel: There are many mature vendor products out there, with powerful and robust    features, and I would advise that it’s probably a mistake for any company nowadays to try to build their own change control system from scratch.

Thanks, Jeff!

Jeff's book, The Project Management Answer Book, is published by Management Concepts (Vienna, Virginia)

Here's the transcription of this video:

Hello! My name is Elizabeth Harrin from the Gantthead blog, The Money Files. And today, I want to talk a bit about some items to include in your project reports, specifically three items to do with financial information.

Firstly, you should include in your project reports a reminder to the stakeholders about the overall budget available to your project and that should be both in terms of what’s available to you this financial year, your budget for this financial period, and your budget overall for the duration of the project or program if it goes into multiple financial periods. Say for example, it’s a program that has a long duration.

You should also include how much you’ve actually spent to date, so your running total. What is it that you’ve incurred cost-wise so far on this particular project?

Finally, you should include a comment around whether or not you are actually on track and that means: Will you hit the budget within tolerance at the time the project closes? So you might think of this as estimate to complete.

You can talk about whether or not you’re on track in your project report with a red, amber or green status or you could specifically mention estimate to complete or you could talk about a percentage of spend.  Or you could just a commentary that says: “We feel that with the current progress of the project we will be on track to complete within the current budget.” Your finance department or your project stakeholder might want some more justification behind that. But if they do, they can always ask.

So those are three things that I think you should include in your project reports with relation to financial topics. Thank you for listening.

This year I am once again running the Social Media in a Project Environment survey. This time last year lots of you completed the survey and the results (which you can access on my blog; scroll down to Social Media Survey Results 2010) provided a snapshot of how social media tools were being used by project managers and in project environments.

This year I have tweaked the survey slightly to give us clearer results, but it should allow for a comparison between 2010 and 2011. As before, there are 9 questions which take less than 5 minutes to complete. The last question gives you the option to enter your email address to receive a copy of the results when they are available.

Click here to complete the survey now.

The survey closes at the end of February, so you still have a short time to complete it.

Thank you!

I’ve held on to Business Case Essentials: A Guide to Structure and Content by Marty J. Schmidt for quite some time, so apologies to the author for taking so long to review it.  The reason it’s taken a while is because I’ve been using it.

The book started life as a white paper in 1998 and has grown to book size over the years in response to requests from Schmidt’s consulting clients.  The author’s aim is to provide a step-by-step guide for building a business case.

Project managers sometimes get involved in the analysis that goes into working out if a project is worth doing or not, and that’s where the business case comes in.  The book is set out logically, and is very pragmatic:

“A successful business case meets these criteria:

• Credibility: The case is believed.
• Practical value: It enables decision makers and planners to act with confidence.
• Accuracy: It predicts what actually happens.”

The book uses examples from real business cases to illustrate what should go into a case and how best to structure the business case document.  Schmidt favours an approach that includes an executive summary, sets out various scenarios, documents the business objectives and describes the proposed actions.  This is set out in Chapter 2, and the remainder of the book is given over to putting some content into each of those sections, with specific emphasis on financial metrics.

The approach to benefits is particularly useful, as people often struggle to quantify the benefits that projects deliver.  It also cuts through the bad practices you may have come across in the past:  “Truly intangible benefits and costs do not belong in a business case,” Schmidt writes.

In fact, even if you aren’t preparing a business case, some of the information about cost modelling in Chapter 3 would be useful for planning a project budget.  Ideally, you’d see the business case (if you weren’t involved in developing it) but for projects that are approved without one, the cost model section in the book would help you construct a valid and pragmatic budget.

There is a lot of information about Monte Carlo simulation and risk analysis in Chapter 5.  This section is technical, as Monte Carlo simulation requires simulation software designed for the purpose.  However, there is also a short section on simple sensitivity analysis, which is basically changing the underlying values and assumptions in your cost spreadsheet and watching what happens to the results.

Overall, this is a useful reference book to have for those times when someone says, “Can you help me write the business case for my project?” 

You can read the original white paper online. If, after that taster, you want to buy the whole book, it’s available as an ebook in .pdf format or you can get a printed version from Amazon.