A Project Charter for Lazy Teams

A Project Charter for Lazy Teams
By James King

I have been creating a couple of articles on this context recently – the idea is that if you know a bit about your users and the product that you are building. Both can take months or years, but I like to think we can even spend an hour or less to understand our project.

When you think about it though, shouldn’t we do a similar thing to define our project purpose when we start the project. I guess the answer is yes, but it could turn into a lot of work. So what we need is an easy, lazy approach.

This is what I think you can do on just about any project.

1. Define the problem you are meant to solve.

2. Define your scope.

3. Flavor to taste:

   1. Consider PAC (People, Activities, Context) to define the users

   2. Consider defining your product

   3. Consider adding an estimate

   4. Consider listing risks and other bad stuff

Paragraph one – choose one of these problem statements

• Problem statement from the book Fierce Conversations by Susan Scott (you should really read this book if you want to be both lazy and successful at the same time):

  • The problem we have is ….

  • It matters because ….

  • Ideally what we would like is …

  • So far we have done …..

  • Therefore, what we want to achieve next is …

• Focusing question

  • How can [We] provide [Something] to [someone] so they can [do something or get some benefit or deal with some issue]

  • Eg – how can the IT team provide a database to Jenny so she can run her coffee club. OR how can Jenny provide a coffee club to her customers so they can buy coffee to take home

• The old fashioned story/legend format, which is the simplest you can use.

  • Currently [things are like this] but it sucks because [some annoyance] so we will [resolve the issue]

  • For example Jenny runs a coffee shop and she would like to sell take home coffee to customers so we want to create a coffee club to do this. Or Jenny has set up a coffee club for her customers but she is losing track of all the information she needs to track so we are gong to build her a database.

Paragraph two – say what is in scope and what is not

No project ever fully solves a problem from every possible angle. If you build software, maybe you should train people and maintain the software. But even if you maintain the software for 5 years, at some point someone should replace the software with a better solution. But even if your project team agree to come back and replace the software, will they be the ones who pay for the carbon offset to make up for the extra greenhouse gases produced during the project lifecycle.

People generally understand that some things will be in scope and that others will be out of scope. Yet we often make wildly different assumptions about what actually goes into the scope.

So I think it is useful to define the following in at least some detail:

• This is in scope – deploying a database, maintaining it in production; and

• This is out of scope – ongoing training, maintaining the customer data.

This is often put into a table with the in-scope stuff on the left and the out-of-scope on the right.

But if you are a vendor or you are delivering to a demanding internal client you might choose to go one step further:

• The project team will deliver (in scope) – deploying a database

• The customer will – provide the team with access to users, supply coffee, provide testing

• The following is out of the scope of this project – ongoing training

Paragraph three onwards.

• Add constraints or priorities if you want to. For example it needs to be in production before Friday next week (eek)

• Add PAC, Product statement or risks if you like

• Add an estimate of the effort involved if you want to

• Add the name of the sponsor, the provider and others if you really want to push the content.

If you want to you can even add a communication plan, a view of whether users will actually adopt the change we are implementing or a test strategy, but not all projects will need this much detail at the beginning.

A simple estimate

People often hesitate to provide estimates. But you can provide something as simple as this: We are 90% confident that the project will take between X and Y. We could be more confident if [something]. For example:

• We are 90% confident the project will take between 50 and 150 years (let’s kill it now);

• We are 90% confident the project will take 3 developers between 3 and 5 days (let’s do it); or

• We are 90% confident the project will take between 3 weeks and 4 months. Hmm –

  • We can kill it if 3 weeks is too long;

  • We can get started if 4 months is tolerable and report back as we go. We will be more confident once we install the invergolator and get it running on windows 7; or

  • We could do more analysis. This would add one week to the project but when we understand your needs better and review the deployment options for invergolators then we can provide a better estimate. Let me know what you want us to do.

I have often found these estimates are enough to make informed decisions. But if you want to get far better at estimating then you should probably read “How to measure anything”. That book even teaches you to estimate and understand the value of doing more estimates. But the lazy approach is just to do what I did above.

What do you think?

It seems pretty basic doesn’t it. So your project should probably have a more detailed description that everyone understands (the stakeholders and the team working on the project). But in practice I have often found a simple summary of the project is enough to make do.

In fact my quote for the day is:

Projects where everyone has the same simple understanding of the problem do better than those where some of the team have a really detailed understanding that is different to what the rest of the team understand.

James King has extensive business and IT experience which he brings to every training and consultancy project he is involved with. A senior project and consulting team manager, James has a successful track record in aligning technology and people to process improvement initiatives that achieve strategic business performance improvements. James holds a Masters degree in business and technology. You can read more from James on his blog.