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
- Project Objectives
- Risks/ Constraints/ Issues
- Communication Plan
"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.
- Define - This is where we're focussing today.
- Plan - Scheduling, resourcing, budgeting
- Manage - feedback, managing progress, negotiating for resources, resolving differences
- 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.
Business Objectives - Using the Greek Goddess IRACISBusiness objectives are one of the following and that's where the IRACIS mnemonic
- Increase Revenue
- Avoid Cost
- Improve Service
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 scopeLou 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 ObjectivesOnce 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
Establish Risks/ Issues/ ConstraintsThis 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?
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 ConstraintsThere's the age old project management triangle:
Plan communicationsAsk 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?
Establish Change Management PlanThis 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.