Personal productivity

In running teams and departments I have always been surprised at the variety of personal time planning approaches people adopt, ranging from the hugely organised to the completely event driven. I believe that personal organisation forms the bedrock for team productivity – for that reason I always encourage people to use some productivity approach and mentor them if they don’t.

There are a number, but the best in my view is still “Getting Things Done” by David Allen. It is the only approach to have a basis in formal theory, indeed philosophy. There is a website – in fact a minor industry – dedicated to GTD, I shall quickly summarise the basics.

Objectives

Document all the tasks you need to accomplish in a system other than your memory. Include tasks to be worked now and in the future. Include both work and personal tasks.
Consult your lists often so you’ll make wise decisions about the next task on which to work.

Benefits

Stress is reduced because you won’t have to worry that you forgot about important tasks, or that items have fallen down cracks.

You won’t forget about important tasks, and items won’t fall down cracks.

You will make better choices about what to do at any particular time, taking into account where you are and what resources you have available.

Managing Workflow

GTD is fairly straightforward. It consists of five stages:

1. collect inputs
2. process inputs
3. organize results
4. review options for next actions
5. carry out a next action.


GTD workflow copyright David Allen Co

Collect Inputs

Inputs include:

  • notes written on scrap paper, napkins, etc.
  • notebooks
  • email (the most common in our business obviously)
  • calendars
  • flyers/magazines
  • books
  • anything you’ve accumulated on your desk

.
Process Inputs

Here are the steps to follow when processing each of the collected inputs.

First determine whether some action needs to be taken at all.

If it does require action then determine the next action that is required. This must be a tangible activity. For example, instead of “update docs”, an action could be “produce quality strategy paper”.

1. Do it if it can be completed in two minutes or less.
2. Delegate it if you are not the right person to do it and it can be delegated to someone else then add it to your “Waiting For” list to track its completion.
3. Defer it by documenting it as something to be done later:

  • If it requires multiple actions, create a project for tracking the actions and document them (a project is just a task that requires more than one action to complete)
  • Document the required action(s) in either a calendar (for date/time-specific reminders) or a “Next Actions” list (for non-date/time-specific reminders).

If it doesn’t require action then select one of the following options.
1. Throw it away
2. Incubate it by adding it to your someday/maybe list
3. Store it in your reference filing system (ideally searchable such as Evernote).

Organise results

Information related to projects and tasks (actions) will be stored in the following locations.

  • project list
  • “next actions” list categorized by project and context
  • calendar for “hard” date or time specific actions that must be performed (for example appointments and meetings)
  • reference files
  • “waiting for” list list to track actions you are waiting for others to complete
  • “someday/maybe” list for actions which you will get to/ plan at some point but don’t want to forget

There are lots of ways you could maintain the lists and storage. The obvious for us is computer support.

Ah, but where to start? Google GTD and you will find hundreds (almost) of packages, advice, books on implementing GTD. Do whatever works for you, on the mac omnifocus and things are good, on windows I always found outlook great provided you created categories for NextActions, WaitingFor, Read/Review, Someday/Maybe and Projects.

Actions are also categorised by Context. A context describes a basic requirement that must be met in order to do an action. It can be

  • a location (such as home or office) where you need to be, or a meeting you need to be at
  • a specific tool (such as a phone or computer) that must be available
  • a person (such as your boss) that must be present

Review options for next actions

There are three techniques for deciding what task to perform at any given time.

Four-Criteria Model for Choosing Actions in the Moment

1. Only consider actions that can be performed in your current context (defined by your location and the set of resources available).
2. Only consider actions that can be completed in the amount of time you have available. Actions should be defined as small as possible and not require multiple steps.
3. Only consider actions that can be addressed given your current energy level.
4. Decide between the remaining actions based on their priority or payoff.

Threefold Model for Evaluating Daily Work

The next thing you do can be one of:

1. Do an action from your “Next Actions” list.
2. Do work as it shows up if it is more important than anything on your “Next Actions” list.
3. Define additional work (adding to your lists) based on new inputs in your in-basket, email, voicemail and meeting notes.

Carry out a next action

And away you go…

Reviews

Reviews are what makes GTD work over time.

At least once per week, review all incomplete items in your lists and flag the ones that need to be addressed soon.

At least once per year review the content of all the folders in your reference filing system and throw out items that are no longer relevant.

Once a week or less, review your “Projects”, “Waiting For” and “Someday/Maybe” lists to see if anything in them needs to be addressed soon. This review can generate new items in the “Next Actions” list.

At least once per week but ideally daily, gather new inputs and add them to your system.

Six-Level Model for Reviewing Your Own Work

There are six perspectives from which to view tasks is order to assign priorities to them. Consider how completing a given task will help to achieve the following.

life goals
3-5 year goals
1-2 year goals
areas of responsibility
current projects
current tasks

So that’s it. Believe it or not, that’s a synopsis of the approach – for more information I recommend the book.

A word of warning. GTD and task management generally is easy to get sucked into and find yourself spending more time organising tasks than you do actually doing them (trust me, I’ve been there. It’s a geek thing).

But there is no doubt that in the fast paced business we are in you need some approach to organise our time. So find something that works for you. Then get on with the actual tasks you need to do!

Agile project management

It is interesting – and somewhat telling – that I have sometimes been asked by business representatives “But what does a project manager actually do?”

Of course in a traditional waterfall project this is well understood. The PM is the key person responsible for planning and delivery to the plan, managing communication, risks, changes and issues along the way.

But what about an Agile project? Surely an Agile project team is self-managing, and the business end is handled by the Product Owner?

Well perhaps. But in practice most companies who have used Agile for more than just small, discrete projects have found, unsurprisingly, that there is a need for a project management role also.

The best analogy I have seen here is from Steven Thomas

“The role of the Project Manager is subtly different when using an Agile approach. From my fairly biased view an Agile PM is more a shepherd (or sheep dog) and less a military officer. There is lots of rushing around the edges of the development team but relatively little direct control of what the team does. If you merge together a description of the Project Manager, Scrum Master, Coach, and Tracker from XP, DSDM, Crystal Orange and Scrum you get:

Gather information from all stakeholders and integrate into workable plan; log estimates; advise programmers on their estimates using historical figures; log task assignments; sustain high rate of progress; make decisions; remove impediments; build and sustain team culture; ensure team sticks to process; liaise between management and team; manage customer relationships; fend off “feature creep” and other project hazards; get agreement on the prioritisation of requirements and detailed content of timeboxes; track progress against the timebox goals/plan; collect information without disturbing the process; update plans; communicate progress; ensure that the lessons are learnt; log defects; stay calm.

Things like “remove impediments” and “build and sustain team culture” aren’t normally seen in traditional PM role descriptions. Then there are the softly, softly items like “collect information without disturbing the process” and “get agreement on …”; and notice we “log task assignments” we don’t “assign tasks”. However, when the crunch comes we must still “make decisions”.”

In their paper “Agile project management” Maven make a similar point

“Whilst the role of Project Manager and Team Leader exist as they do in PRINCE2 , the emphasis on the responsibilities is very different and this can cause some adjustment for those project managers coming to Agile from a waterfall background.

The project team is empowered to plan their work in detail and to address issues as they arise with whoever is best placed to solve them. This means that not all communication comes through the Project Manager. [He is] not formally managing the project team, but must be on hand to guide them and to help remove any obstacles that will impede their progress. At the same time, [the PM needs] to be fully aware of the progress that the project team is making so that he or she can relay this to the stakeholders and ensure they have enough information to assure themselves that the project is on track and will deliver what they need.

For project managers used to planning every aspect of their project and conveying this information to team members via detailed work packages, this lack of control over the day to day work can appear threatening. This is why trust and honesty between the team and the Project Manager is vital, as is knowing when to stand back and let the team get on with their work.”

So there you have it. More guidance, less direction. Less a military officer, more a sheepdog.

Stakeholder analysis

Stakeholder management is critical to the success of every project. By definition larger projects and programmes will affect more and more people. The more people you affect, the more likely it is that your actions will impact people who have power and influence over your projects. These people could be strong supporters of your work – or they could block it. Stakeholder Management is an important discipline to help win support from others and Stakeholder Analysis is the technique used to identify the key people who have to be won over.

One of the key benefits of using a stakeholder-based approach is that you can use the opinions of the most powerful stakeholders to shape your projects at an early stage. Not only does this make it more likely that they will support you, their input can also improve the quality of your project Gaining support from powerful stakeholders can help you to win more resources – this makes it more likely that your projects will be successful By communicating with stakeholders early and frequently, you can ensure that they fully understand what you are doing and understand the benefits of your project – this means they can support you actively when necessary You can anticipate what people’s reaction to your project may be, and build into your plan the actions that will win people’s support.

The first step in Stakeholder Analysis is to identify who your stakeholders are. The next step is to work out their power, influence and interest, so you know who you should focus on. The final step is to develop a good understanding of the most important stakeholders so that you know how they are likely to respond, and so that you can work out how to win their support – you can record this analysis on a stakeholder map. The steps of Stakeholder Analysis are explained below:

Step 1 – Identify Your Stakeholders The first step in your Stakeholder Analysis is to brainstorm who your stakeholders are. As part of this, think of all the people who are affected by your work, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion. Often people include members of the project or programme team as stakeholders. I don’t generally – after all, you will probably have enough stakeholders to deal with, and I feel that the way you interact with team members is fundamentally different from the way you interact with stakeholders. However it is worth remembering that internal managers – the people your team report to in a matrix managed organisation – are often key stakeholders for you

Step 2 – Prioritize Your  Stakeholders You may now have a long list of people or organizations that are affected by your work. Some of these may have the power either to block or advance. Some may be interested in what you are doing, others may not care. Map out your stakeholders on a Power/Interest Grid as shown in figure 1, and classify them by their power over your work and by their interest in your work.

image
Figure 1

For example, the Senior Responsible Owner in MSP is likely to have high power and influence over the project and high interest. Peer managers may have high interest, but are unlikely to have power over it. Someone’s position on the grid shows you the actions you have to take with them: High power, interested people: these are the people you must fully engage and make the greatest efforts to satisfy. High power, less interested people: put enough work in with these people to keep them satisfied, but not so much that they become bored with your message. Low power, interested people: keep these people adequately informed, and talk to them to ensure that no major issues are arising. These people can often be very helpful with the detail of your project. Low power, less interested people: again, monitor these people, but do not bore them with excessive communication.

Step 3 – Understand Your Key Stakeholders You now need to know more about your key stakeholders. You need to know how they are likely to feel about and react to your project. You also need to know how best to engage them in your project and how best to communicate with them. Key questions that can help you understand your stakeholders are: What financial or emotional interest do they have in the outcome of your work? Is it positive or negative? What motivates them most of all? What information do they want from you? How do they want to receive information from you? What is the best way of communicating your message to them? What is their current opinion of your work? Is it based on good information? Who influences their opinions generally, and who influences their opinion of you? Do some of these influencers therefore become important stakeholders in their own right? If they are not likely to be positive, what will win them around to support your project? If you don’t think you will be able to win them around, how will you manage their opposition? Who else might be influenced by their opinions? Do these people become stakeholders in their own right? A very good way of answering these questions is to talk to your stakeholders directly – people are often quite open about their views, and asking people’s opinions is often the first step in building a successful relationship with them. You can summarize the understanding you have gained on the stakeholder map, so that you can easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters or your project. A good way of doing this is by color coding: showing advocates and supporters in green, blockers and critics in red, and others who are neutral in orange.

When you have identified the stakeholders and analysed their impact on the project or programme, you need to move on to decide what you do to manage them. This is covered in the next stage, stakeholder planning.

Roles in an agile programme

One of the common criticisms made of agile is the inability to scale to large systems and programmes. It seems worthwhile, therefore, to think about the differences in agile structure between a programme and a project.

Just as in waterfall many programme roles relate directly to those in a project. However the programme level is fundamentally about business outcomes rather than project outputs and therefore focusses on business change implementation and benefit realisation, functions not normally found in projects. At development level though, the responsibility is larger and coordination greater but the roles are basically the same. The Programme Manager, Product Owner and Technical Architect roles are like this, corresponding to Agile Project Manager, Product Owner and Technical Lead.

In addition a programme needs some roles that don’t appear at all in a project, notably Programme Director and Business Change Manager. Again these roles are a result of the increased scope and communication necessary in a programme and also because of the focus on organisational change.

Programme Organisation Chart

Lets look at a typical agile programme organisation.

agileorg

The people in the technical teams (product development, integration, infrastructure) have Agile project roles. The Agile programme roles are in the Programme Board (Agile Programme Manager, Programme Director, Programme Product Owner, Technical Architect) and Change Implementation workstream (Business Change Manager).

Programme Director

The Programme Director is a senior manager responsible for the overall success of the programme. He/she is the final point of responsibility at the programme level.

The Programme Director is the key manager in ensuring the programme remains aligned to corporate strategy.

Typically the Programme Director is the business sponsor for subordinate projects. They might also be the Programme Product Owner and could be the Product Owner for the Technical workstreams.

MSP actually expects a Senior Responsible Owner (SRO) at the head of a programme although it accepts that some organisations have a Programme Director instead.

Programme Product Owner

The Programme Product Owner is responsible for the entire product being delivered by the programme team. Normally the Programme Product Owner is a different role to the Programme Director but the two roles can be held by the same person. As the size of the programme grows the Programme Director will definitely have to delegate increasing amounts of product responsibility to other people. At some point the two roles split.

MSP doesn’t have the concept of a Programme Product Owner as many programmes are not about building something (although our interest is software development).

Agile Programme Manager

A Programme Manager is responsible for the programme from programme setup (including governance), through the delivery of the capabilities and benefit realisation, to programme closure. A Programme Manager has to do all the normal project tasks (Planning, Monitoring and Control, Change Management, Risk Management) but at the programme level.

In addition the Programme manager must shape the programme team including subordinate projects. They need to form the various teams, manage the interdependencies beween them and ensure the projects deliver as tasked.

Technical Architect

The senior technical person on the programme is usually a Technical Architect. They have overall responsibility for technical quality of the product including how it is structured, organised, and implemented.

Business Change Manager

The Business Change Manager (BCM) is an MSP role. It doesn’t appear in a project (Agile or not). That is because a programme is about business change and a project is about delivery of outputs.

The BCM’s role is to manage the organisation through transformation. The programme might create capability but it is up to the BCM to ensure the organisation adopts the products and whether the organisation achieves the desired benefits.

The nature of the role, including close stakeholder contact, means a BCM is usually from the business. The role can be full or part time, long term or short and are often local champions recruited to support roll out in their area.

Recruiting project managers

In the past I have put a lot of effort into recruiting, mostly project managers. In terms of delivering, the project management level is key. You can have a successful project with a bad PM, but in my experience only if someone else (typically the team lead) takes over the PM role. So having spent a long time doing this, I thought I’d write down what makes a good project manager and how you know when you are interviewing one.

Lists of qualities

If you ask people what makes a good PM they will typically say things about Communication, Vision, Enthusiasm, Delegation, Calmness (I could go on).

The problem with these definitions is that they focus on defining the person rather than what the person can achieve. They’ll get you a project manager, yes – but not a great one.

What a candidate has done is plainly important. But just as important is how they have done those things. There are two types of things we should be looking for in a great PM.

Look for excellence

Aristotle said that “We are what we repeatedly do. Excellence, then, is not an act but a habit.” If somebody has that habit it will show, not just in their work but in everything they have done (including their approach / preparation for interviews).

Therefore you should look for achievement in any area of life – what you are looking for is not so much what they did but the approach they took to doing it and the result. Yes, many people can say they are in a band or their hobby is keeping fit. Dig deeper. What have they achieved in that hobby? What role did they play in it? You are not necessarily looking for overachievement (although that is no bad thing) – you are looking for a clear goal and plan followed by excellence in the achievement of it.

Learned behaviours

Well OK, we would all agree that excellence is something we want to see in all of our people.

Learned behaviours, however, are role specific. A project manager needs a different set of behaviours than a developer, and both of them to a tester. I think a great project manager should consistently show a history of:

  • Finishing tasks
  • Building good teams
  • Dealing with complexity

Let’s look at each of these.

Finishing tasks

A talent for finishing is different to the Completer Finisher role. The Completer Finisher is a perfectionist and as we all know this can actually get in the way of finishing.

Good project managers are focussed on the final goal. They prioritise so that the most important stuff happens soonist and are happy to sacrifice the unimportant activities to do this. They are impatient with tasks that are 95% complete and the people who never seem to get past that. They know what is happening on the ground, and they can spot problems in advance. They are thorough and have high standards yet know that “perfect is the enemy of good”. They do the work themselves if there is nobody else to do it. Nothing will stop them until they are finished and complete.

So look for project managers that have a history of finishing. At work and in their personal lives.

Building Great Teams

Great project managers have a history of forming great teams. They know that they can get more done with a strong team behind them. They focus on people as well as tasks. They are expert at managing-up and include wider stakeholders such as sponsors and customers in the team. They trust and are trustworthy. They apply tough love. They deal with under performance quickly as they know it threatens the team. But they believe everyone can do well in the right role. They are proud of their team and what they’ve done together.

So look for a history of team work and team building.

Dealing with Complexity

Great project managers are used to dealing with complexity. They think clearly, easily cope with a lack of complete data, are creative in solving problems, and balance risk confidently. They are flexible, adapt processes to fit the local need, and reject a one-size-fits-all approach. They know when to bend the rules to make progress, when to intelligently disobey. They can deal with many tasks at once; they might drop something, maybe even a lot of things, but they never seem to drop anything important.

So look for recurring patterns of adaptability and creativity in the face of complex challenges.

What about Knowledge and Experience?
I think knowledge and experience are less important than the points listed above. I have met lots of people who know all the theory, but who are complete failures when given a project to lead. The project manager needs to understand what they’re doing and what the team is doing but this understanding isn’t, by itself, any guarantee of performance.

The most useful understanding usually comes from a combination of learned knowledge and practical experience. Look for understanding in three areas to supplement behaviours:

  • Project Management Understanding
  • Technical Understanding
  • Domain Knowledge

Project management understanding

A project manager has to know the their profession. Know what a Gantt chart is. Know how to put together a valid, workable plan. Know what to put into a status report and know when it is okay to have a discussion instead.

Regarding software development, a project manager has to know user stories, velocity, story points, sprints, stand ups, release management, sprint reviews, planning poker, team estimation and so on.

This stuff is all trainable, but generally to have turned this into deep understanding, the person will have had practical experience.

Technical understanding

Technical Understanding means the project manager can understand the job being done by the people on the team. Usually that knowledge comes from having done the job in the past. So most of the good software development project managers I know have been developers in the past. They don’t have to have been good software engineers, or still be able to do it, but they do need to understand what developers are talking about when describing tasks and problems, and understand the problems developers face.

Domain/ market knowledge

Whereas project management understanding and technical understanding are critical, domain knowledge is nice to have. It helps if the project manager knows what the business does. But a good person can pick this up as they go along.

Its odd that domain knowledge is ranked so highly by HR teams and recruiters. I think this is because its easy to do. Recruitment today is – unfortunately – a numbers game. Searching for key words, be it sector background or technical background, is a simple way to cut those numbers down. Unfortunately it misses out the really important points we should be looking for.

Summary

So there it is. If you need a project manager look for somebody with a proven history of building great teams, who can handle complexity, and most importantly, with a background of finishing. They need to understand project management practices (ideally Agile and waterfall/ gate based) if applicable, and the technical job as well. Sector knowledge is a bonus. But pick talent over knowledge every time.

Some consider it noble to have a method; others consider it noble not to have a method. Not to have a method is bad; to stop entirely at method is worse still. 

One should at first observe rules severely, then change them in an intelligent way. The aim of possessing method is to seem finally as if one had no method.

Chieh Tzu Yuan Hua Chuan
The Mustard Seed Garden Manual of Painting (Qing Dynasty)