Training Mag Webinar - Learning Project Charter in 45 Minutes?: It's Important and CAN be Done!

Now let me confess, I didn't know of Lou Russell until I joined the Training Mag Network. That's because I often overlook authors from some of the books I casually pick up. Lou's better known in the community as the author of The Accelerated Learning Fieldbook. She also heads up Russell Martin Associates. Today's topic actually interests me primarily because I find the title catchy. I'm no expert project manager and in fact I'm crap at it. That's why we need people like Krishnan Nair. That said it's a skill I'm always interested in, particularly from the learning and development perspective. Having worked for ThoughtWorks and having been an ardent follower of Cathy Moore's action mapping approach, I've usually done my project 'charters' in a highly lightweight fashion. I'm keen to know about what Lou recommends however and that's the motivation behind attending today's webinar. So Lou, I'm all ears!

These are live blogged notes from the webinar. Lou confesses to being a shiny object person, like me. She talks about her techniques as things that allow her to stay focussed without the need for save the world heroics.

Lou says that you should be able to do a good enough project charter in 45 minutes or less and you particularly need to answer why you're doing the project in the first place. You're actually drawing up a draft and a placeholder for conversation. It's a best guess for what you're trying to achieve and then you need to keep evolving the vision with stakeholders. If you spend more than 45 minutes for this -- you're perhaps doing something wrong.

So what are our deliverables?

• Business Objectives
• Scope
• Project Objectives
• Risks/ Constraints/ Issues
• Communication Plan
• Governance

"Project management is only about communication -- anything that doesn't communicate, is not useful!"

In Lou's school, she talks about the following steps to manage a project -- it's a bit linear, though I know this is fairly well followed in the PMP community. In fact Agile or not, most projects still look like this.

1. Define - This is where we're focussing today.
   
2. Plan - Scheduling, resourcing, budgeting
   
3. Manage - feedback, managing progress, negotiating for resources, resolving differences
   
4. Review - final delivery, support, (post mortems/ celebrations)

"Bad news early is good news."

While you can't discover all the bad news upfront, it's nice to be able to find ways to identify stuff early. Fair enough, though iterative development can help surface issues through the actual act of executing the project. That being said, a great project inception is an auspicious start to your project.

For the purpose of this session, Lou is introducing a fairly typical case study. Here are the key points about the case study:

• We're creating a one hour elearning module to teach people to fill out an expense form.
• There's already a one hour, Powerpoint based instructor lead course in place.
• We need to add voice overs, interactions and a knowledge check (Why??).
• We're using Articulate.
• We'll adminster the course using our LMS (hope it's not crappy).
• We have an SME for the project and the accounting department is paying for it.

Let's now try to answer some of the questions likely to arise using Lou's techniques

Business Objectives - Using the Greek Goddess IRACIS

Business objectives are one of the following and that's where the IRACIS mnemonic

• Increase Revenue
• Avoid Cost
• Improve Service

So what's our objective - we want to avoid cost of inaccurate travel expense filing and form usage which could lead to rework from the accounting department. For this, all we need to do is distribute a 1 hour module to the entire community. (Ambitious, but OK - I'll play along).

That said, the project sponsor decides the business objectives -- so the idea is to ensure that we don't send a blank slate to them. A better idea is to try and take a stab at it and send that across. There may be more than one business objectives, but it's perhaps a better idea to pick out one with the project sponsor and determine the one that's most important. A good question is, "What made you call us?".

If you don't have a business objective, then you perhaps don't have a reason to do this project.

Establishing Project scope

Lou introduced this matrix for PMs to try and establish project scope. For example, the sponsor will provide budget/ time and will need status of the project. OTOH, the SMEs will provide us the form for the course and common mistakes and we'll provide them drafts. As you fill this out, you'll develop a complete list of what you need and what you need to provide. This gives you a fair list of items you need to provide.

I'm a little sceptical about this being a definition of scope though, because I feel it creates a list of artifacts, but not necessarily scope -- I look at it as the breadth and depth of the project. I guess however that the comments section may provide more detail for this.

But then, now Lou's showing us a nice diagram that illustrates a give-get relationship with various stakeholders on the project. I still am a scope management bad-cop and on my projects I'll be a little scared if we called ONLY this scope. That said, we have a whole bunch of things to go through, so I may be jumping the gun!

A good tip from Lou - don't depend on communication you can't control. Keep that as a nice-to-have, try to influence it, but don't count on it?

Another good tip -- when you draw out communication channels, don't oversimplify the picture. Draw every communication channel separately - avoid double headed arrows since they avoid accountability. Hmmm...

I like this, because this kind of analysis already starts to give us a bit of a communication plan and a list of responsibilities on the project.

"Keep things hand-drawn, so no one assumes it as a done deal." Things need to be open for change.

Develop Project Objectives

Once you've got your above diagram/ matrix ready, then you can develop your project objectives. This is basically to determine the project level goals like:

• Every student takes a post-test for course completion
• The module should be compatible with the LMS

You can also mix in Learning objectives with this -- I don't really like learning objectives any more, though I think you can mix action mapping with this approach.

Establish Risks/ Issues/ Constraints

This is the time for you to determine a few things:

• Size of the project -- How big is this relative to projects you've done before?
• Structure - How volatile are the requirements? What's the likelihood of change?
• Technology - How well do you understand the technology and procedures?

Remember the higher the risk of these factors, the more you're going to spend time on the project as a manager. And these factors could be different for different teams.
Lou put's out this table to record risks and to maintain a risk log. This is quite similar to what I've seen and used in the past. This is something to keep revisiting through the project, so you can keep looking through your risk log, see their current status and look at whether you need to get your mitigation strategy in place

Document Constraints

There's the age old project management triangle:

• Time
• Cost
• Quality/Scope

One of the things that could be useful to determine up-front Lou says, are the constraints on each front. What's the constraint on cost or time or scope or quality? To me quality is not-negotiable, though I guess this means that you have some tolerance about known issues, etc.

Plan communications

Ask yourself:

• Who will you communicate with?
• What do they want to know?
• What communication format and frequency is best?
• How much time do you have?

No news is bad news! So communicate often and in time!

Establish Change Management Plan

This is where you decide who takes care of which change. For example who deals with change in budget and schedule? Who takes care of changing requirements? And finally who deals with quality issues?

This could be quite useful in deciding responsibilities on a project as well. Hmmm... I like this more than I expected.

So, this is 45 minutes not badly spent and despite my sceptism for most traditional project management, I must say Lou's tips did make overall sense, because she focussed so much on communication. I like communication. 

"Anything that can go wrong will go wrong!" - Murphy

An experienced project manager manages risk well and communicates well - is what I think Lou was trying to paraphrase. Yes, I like that -- that's being a realist.