Helping the accidental project manager

One of the aims of this site is to provide project management help to those who stumble into the role of project manager and realise that they could do with a few pointers on what that means. Steven Levy’s No Secret blog talks about the Accidental Project Manager, and considers the benefits and disadvantages of that way of working:

Accidental project managers can have a surprisingly positive impact on [...] projects if they are armed with a small number of project-management “weapons”:

  • They know what they don’t know. In other words, they don’t try to do too much or pretend they have the answers.
  • They have good people skills. That’s probably 80% of effective project management anyway!
  • They have a small, basic set of simple tools to manage — a way to track risks, a way to track tasks/progress, and a way to track costs/resources

It’s true! It’s too easy to get bogged down in process and not consider what it is that you are trying to achieve, but it’s important not to forget that small, basic set of simple tools. Projects need some sort of control applied to them, to make sure that they are heading where they need to go. I look forward to seeing some more information about those tools in coming weeks.

Begin your project with the end in mind

This post from Project Management Tips ties in well with my earlier post about starting a project, and the need for a Project Brief.

“Begin with the End in Mind means to begin each day, task, or project with a clear vision of your desired direction and destination, and then continue by flexing your proactive muscles to make things happen.” This is straight from the 7 Habits book. In my opinion, this applies to both the project view and the daily view of what a project manager is up against.

It’s a reminder of the need to define what you want your project to achieve up front, but also to check back on that definition regularly to make sure you are still on track to deliver what you set out to.

Project briefing guidelines from OpenLearn

Do you want to make sure you have the basics of Project Management sorted – the terminology, stages, structures and processes? You could go on a (very) expensive course, or you could access the materials from leading universities for free through the use of Open Educational Resources. I’ll be looking at some of the resources available and outlining what they cover and what benefits they could bring to your project management.

I am a big fan of the UK’s Open University. I have studied with them for years, and the quality of the materials they produce has always impressed me. They have a new(ish) iniitiative called OpenLearn, where they make some of their course material available as OERs for all to use. Anyone can register with OpenLearn and you can then use the VLE to track your progress and record your learning. Note that there is no tutor involvement with OpenLearn – it is all self-directed learning. If you want to sit an exam and get the support of a tutor and a formal qualification, you will need to sign up with the Open University itself, and hand over some cash.

Preparing a project

The first course I am going to look at is Preparing a Project (B713_1). It is at Masters level, but does not assume any particular qualification. The course outline suggests it takes approximately 8 hours to complete.

It covers the following topics:
  • What is a project?
  • Why projects fail – the dimensions of failure
  • Where do projects come from
    • The idea
    • Mind mapping
    • Task breakdown chart
  • Project inputs and outputs
  • Setting aims and objectives
  • The stakeholders and their interests
  • Will it work?
    • Consider the purpose
    • Feasibility studies
    • Risk and contingency planning
    • Risk assessment and impact analysis
  • A basis for action and the project brief

This unit provides the context for setting up a project. The key points here are:

Section 5 – Make sure you know what you are trying to achieve and will be able to tell when you have achieved it
Section 6 – Think up front about who needs to be involved in your project and who you need to communicate with about it.
Section 7 – Risk analysis. It provides a template for a risk register, and discusses the need for contingency
Section 8 – A checklist of the headings that should be included in your Project brief, or Project Initiation Document.
I particularly like the Project Brief Checklist. It can be quite difficult to find a template or outline for the main Project Management documents, and I think that the headings given here are a great starting point for someone who is trying to put together a Project brief, or who is wrestling with how to get started with managing a project.
Here’s the list:
  • Project title
  • Name of sponsor and main contact for project approval
  • Locations – address of sponsor, project location, contact address
  • Name of person managing the project and possibly their organisation if different from that of the project sponsor
  • Date of agreement of project brief
  • Date of project start and finish
  • Background to the project and purpose with goals outlined
  • Key objectives with quality and success criteria
  • Details of how achievement of these will bring benefits to the business or sponsoring organisation
  • Scope of the project and any specific boundaries
  • Constraints
  • Assumptions
  • Timescale of the project
  • Deliverables and target dates (milestones)
  • Estimated costs
  • Resourcing arrangements
  • Reporting and monitoring arrangements
  • Decision-making arrangements – level of authority and accountability held by manager of project and arrangments for any necessary renegotation
  • Communications arrangements
  • Signature of sponsor with date, title and authority
This looks like a really solid template for a Project Brief. Let me know if you think it is lacking anything.

How to write Functional Requirements

Have you been asked to write requirements for a piece of work, and don’t know where to start? Or are you coming out of a project that has not quite delivered what you expected, and you want to find out how to avoid making the same mistakes again? Hopefully this information about how to write good functional requirements will help.

What makes a good requirement?

Specific, but not prescriptive

Do say exactly what needs to be included.

Don’t say exactly how it needs to be achieved.
If you include too much information about how a requirement should be met, you will be short-circuiting the skills of all the other team members. Let the designer design, and the developer develop. Being too prescriptive leads to designs that tick the boxes without adding anything creative, imaginative or innovative. Leave scope for people to solve problems in ways you hadn’t thought of.

Measurable

Do say how you will know that a requirement has been met.

Don’t use subjective terms.
A good requirement is testable, and in fact a test team should be basing their test plan on making sure that every requirement is covered.

  • Users must be able to see all their transactions for the past 30 days – good
  • Users should be able to tell what they have bought – bad
  • The application should be easy to use – bad
  • The user interface should be designed to be usable by 5 year olds without any intervention by an adult. – good

Realistic

Do include what you need to make a releasable product.

Don’t turn your requirements into a wishlist
Any requirement that starts: “If there’s time…” or “If possible” deserves to be ignored. If you need something – ask for it. If you don’t need it, leave it out. I’ve seen people get round this by adding a priority e.g. Essential, highly desirable, to each objective. If you are going to do this, you need emake sure everyone agrees on the purpose. Is it so that the developer can prioritise their work in case you need to release without all feaures? In that case, it might be better to plan for phases of development. Is it so that these features should be included if they don’t create any extra effort? I would always err on including fewer requirements and achieving them well than setting an expectation for something that might not be delivered.

Completeness

There is a lot of pressure on the person writing requirements to make sure that they are complete. This is particularly true if you are dealing with an inflexible third party company who are going to charge you for any changes. The best way to make sure that requirements are complete is to get a lot of pairs of eyes on them. Users, sales people, developers, customers, designers, marketers, support staff… they all have their own take on what the product needs.

  • Get them involved early
  • Ask them what was wrong with the last version/a comparable product
  • Find out what is causing support calls on other products
  • Find out what customers are asking for but be careful not to get too bogged down in what will please one particularly vocal customer – what will please most of the people most of the time?

There is often resistance to getting too many people involved too early on, because the chance are that you will be inundated with requests for features that will increase the scope of the work beyond what is possible. This is where the Ownership becomes very important.

Ownership of requirements

Someone has to have the final say. If you are expecting an entire committee to sign off anything longer than a page, you are likely to end up in endless iterations. Agree with the committee that Person X is the ultimate authority and if they are happy then the requirements are signed off. If you are going to invite input from a wide group of people (as you should, if you want to capture gaps early) then someone needs to take responsibility for going back to these people and saying “your request didn’t make the cut”. This could be you, or the ultimate requirements owners but it has to be done. The alternative is that everyone expects their requests to be implemented, and it is easier to deal with their disappointment at the start than when you are trying to get everyone excited about a finished product.

Walk it through

Once you have a draft of what you think the requirements are, walk through some typical use. Some people use scenarios or use cases for this – where you map out all the players involved in performing a particular action. Pick a few typical tasks that a typical user might want to perform, and draw them out on a whiteboard. As you move through the process, ask yourself:

  • What am I assuming?
  • Can this task be achieved with these requirements?
  • Will it be obvious to someone reading these requirements that this task needs to be supported?

Do that for a few different tasks and you’ll get a feel for whether or not you’ve included enough information. Use pictures and keep talking.

Finally, if you can refer to diagrams, mock-up, prototypes then do so. Getting a designer involved early will pay off in the long run. The creation of requirements should be a collaborative process between designer, developer and requirement owner. Don’t expect to write the requirements and then throw them over the fence to someone else to produce. Expect it to be an ongoing conversation, and if you can refer to pictures and diagrams during the conversation then even better.

Getting requirements gathered and agreed is not an easy process, but if you can listen to what people are asking for and work with a strong requirements owner, then you’re halfway there. The rest is down to your ability to describe the needs in precise, unambiguous and specific language.

Bigger is not necessarily better - keep it simple! Credit: Florian

Bigger is not necessarily better - keep it simple! Credit: Florian