Meetings – The who and what

Assuming you’ve put some thought into whether the meeting is actually needed or not, then the next step is to think which poor souls will be having chunks of the lives eaten up on a regular basis.

I’ll state up front this is a long post; communication is key to projects and meetings are key to communications. However, there is a lot of room to get them wrong and waste a lot of time. By focusing the meeting to get the maximum value, the result is meetings that are better attended than waffle sessions.

Below I’ll cover two points in detail, but the summary is:

  1. Carefully consider who needs to be in the meeting
  2. Ensure you get the agenda out in advance:
    1. In an agreed format with the pertinent details clearly listed;
    2. With enough details for the attendees to be adequately informed.

(The follow-up will be the next post).

The benefits of a focused meeting pay dividends and make them a useful tool for the project. Alternatively, if you don’t put in the effort up-front then the meetings become a sink and will drain a wider group.

Identify the Victims Attendees

First start by identifying which people are going to have significant chunks of valuable time sucked into the meeting, or series of meetings. One simple rule should be only invite those people who absolutely have to be involved. Spectators are acceptable as long as they remain on the side and passively observing. Agile formalizes this with the chickens and pigs fable, but I think it provides a clear lesson for all meetings. What the project meetings need are knowledgeable and empowered decision-makers. In some cases the notes and agenda provided before the meeting are key to providing that knowledge).

Generally, as soon as you start on a project you should be identifying and updating the sponsors and stakeholders, and this needs to be quickly formalized for everyone’s benefit. The first step is to identify who needs to be there, and that should ideally be people with the authority and experience to make decisions and commit the project to them.

The PMBoK has the Stakeholders identified in the Project Initiation, quickly followed “Plan Communications Management” in the Planning. Since communication is key to a Project is makes sense to cover this very early in the project. Ideally you want to establish a rhythm – daily team meetings, weekly PM meetings, monthly steering, and rules for calling exceptional Aagh!Help!TheWheelsHaveFallenOff meetings. For larger meetings there may well be formal committees with quorum limits; for smaller projects it may be just a single sponsor or their representative who will join. Either way, you need to tailor the meetings and schedule to fit the reality of the project.

When thinking about the potential attendees, there are some people who simply have to be there. The first port of call should be a list of the stakeholders and project teams (the PMBoK has the Stakeholder Register for this listing amongst other details.)

For example, if we’re about to make some decisions that are going to fundamentally change the project then the key stakeholders – especially the ones who pay the bills – must be there, or appoint someone with the full authority and remit to make the decision for them. If the changes are minor, say modifying the delivery dates of some trivial documentation that has zero impact, then it may be enough for just the PMs on each side to decide and commit to the change. Similarly, the Project Sponsor may have set ideas on how information should be provided – some are happy with simple one-page traffic light reports, others want the detail available.

The make-up of the meetings needs to be agreed early on as it will impact the budget and schedule estimates. If it takes two or three days of effort to create the meeting pack for monthly Steering, then for a 12 month project a) you’ll want to bill 36 days to the client and b) you’ll need to get these over to the Steering Committee at least 2 business days out to allow them to review and digest so the meeting can focus on the decide and commit.

Once you have the participants, both you and they will need to juggle availability to get the meetings on the various calendars. This is another reason to get a rhythm established as for longer projects people are less likely to double-book if they know that the first Wednesday of each month is the big project meeting. Similarly, if your steering meetings are pulling in senior staff or C-suite executives then you’d be surprised just how far out they already have commitments.

Now we have the attendees agreed and the meetings committed to mutual calendars, the next item should be the agenda.

The Agenda

In short, the agenda details the items to be covered in the meeting and should include supporting documentation. The first couple of meetings should be used to garner feedback from the attendees to allow the format to evolve to best fit the project’s needs. After a few meetings the format should stabilize to a regular format which will also allow attendees to quickly digest the information.

The only “standard” items I’d suggest for every agenda are:

  • Clear statement of the date, time and place of the meeting;
  • The name of the meeting (eg. Steering Committee, etc.);
  • The chair (ie. who is responsible for running the meeting). Larger projects or PMO teams may have a meeting organizer, in which case their details should be listed.
  • The status of the agenda (whether draft or final) and the security (Client Confidential, Internal Only, Burn laptop after reading, etc.) For confidential documents I’ve found it helpful to state this as part of the filename as well as stating it in the document.

If your teams are located in multiple time zones then make sure the timezone is clearly stated with the time; I normally use the timezone of the chair. (I’ll use chair in this post, however if you’re using a meeting organizer – say your Project Admin team – then you should clearly agree roles and responsibilities as part of the Communication Scope.) If you’re attending from outside the host timezone then be careful in the Spring and Autumn to check for when daylight savings occur. For example, the US and UK put their clocks back in the Autumn at the same time, but the US puts them forward a few weeks earlier than the UK.

It is well worthwhile having a template for the meeting agenda. Once you’ve modified it for the meeting and project at hand, you can the reuse the previous agenda as the base for the next meeting’s agenda. For projects with remote teams, the agenda should include the dial-in details for attendees, and attendees should check before the meeting they can access the dial-in. Sometimes there may be a specific number to call from a country, sometimes it is a generic number. Either way, it pays to take a couple of minutes to dial-in ahead of showtime to ensure that your phone is allowed to access it.

The order can be left to taste or to feedback from the team. I prefer to start with a review of open actions followed by the relevant activity since the last meeting, then cover the key areas of the project that are ongoing. For larger projects this could be a phase by phase approach; for smaller projects it could be all in one.

Whether large or small, the meeting or section should look to get to the decision-making as soon as is practical. The attendees should be in agreement that they are committed to review any supporting documents ahead of the meeting so that valuable time isn’t wasted.

Ideally this should allow the meeting to quickly move to the core reason for gathering people in the first place; is there any significant news, risk, or issue that needs to be address or confirmed at this point in time. This could be regular project activity such as confirming then agreeing/rejecting Change Requests, or updating or adding new risks. However, it could also be more significant; for example, a regulator is proposing a new requirement which could significantly alter the project landscape, or even render its underlying business case invalid.

For organizations where historically meetings were used to update key stakeholders and keep them appraised on any significant issues or changes, the move to meetings that are focused around ‘decide and commit‘ can be hard. One way to get them to move toward this is to go back to what they need (a clear statement on where the project is) and how best to deliver it (via the medium of modern electronic communications, not verbose waffle).

In this situation, the information they need to fully understand the current and future status of the project should be provided ahead of the meeting in a format agreed between the project teams. All parties then review ahead of the call, and the call acts to confirm they have read, understood, and agree with the status. The meeting can make the decision about whether the information is sufficient, and move on.

If there is a question or concern, these should be raised back to the chair before the meeting. The chair can either provide additional information or clarification, or agree there is a genuine issue for the meeting to make a decision on how to address.

From a general process view, if an attendee cannot make a meeting then they should confirm this to the chair; if they are a required attendee then they should provide a replacement with adequate knowledge and authority to make decisions on their behalf.

Another key point is that the meeting should also confirm that the minutes of the previous meeting was accurate and accepted. The minutes are one of the key take-away items from a meeting so I’ll cover that in a future post. Some clients prefer that the previous meeting’s minutes are included with the agenda, some do not, most are agnostic – however, make a point to at least discuss which approach and agree.

If the minutes are disputed, do not use the meeting to argue it out unless either a decision can be agreed quickly, or the dispute is so fundamental as to be a roadblock. Otherwise, it can be noted there was dissent, and whether any follow action was agreed. Issues with the minutes should ideally be raised ahead of the call as per questions about the status. If the issue is agreed as too significant to agree outside the meeting, then the details of the contention should be provided with the agenda to allow the meeting to review and then move to quickly and decide how to resolve.

Generally, the Agenda should list all those matters which the meeting needs to discuss in detail and which require some action or decision. If this needs to refer back to some other document provided with the agenda you may want to consider noting the document and page so people can find it quickly if then need to cross-reference.

The list of agenda items (which is apparently called the agendum) should see each item consist of a clear and accurate heading that concisely describes the item. For regular meetings these items should be consistent from meeting to meeting so encourage a regular flow to the meetings and allow them to be quickly tracked down in minutes, etc.

Since we’re trying to position meetings to focus on ‘decide and commit’, for each item we should either state in an agenda a recommendation for consideration, or at least have one or two in mind. (As a general rule whenever I bring an issue to a meeting or manager I always like to have some ideas of how it can be fixed, removed, or absorbed). For these recommendations we should also be clear whether the recommendation is one that the Project team has reviewed and recommend the meeting accept and commit to, or is simply one that the team would like the meeting to consider.

Some agenda lists are simply a series of bullet points, especially for smaller or more informal meetings. For large, or formal meetings (such as decisions on whether to continue a project or move to the next phase) it may be more beneficial to have pertinent background information and reference back to other documents as needed (minutes, scope documents, etc.) Of course, this also means more due diligence off the chair before the meeting to make sure all these documents are available to attendees and are correctly referenced. If you are going to recommend a course of actions, make sure you have the information to justify your decision.

I find that regardless of the list of agenda points, the last one should be “Any Other Business” to allow the meeting to capture anything that was missed ahead of time that really cannot wait.

Finally, I always find it useful to confirm the date and time of the next meeting – particularly handy with multi-site/national teams that observe different holidays.

Hopefully this should all lead to a quick and productive meeting with the minimum waste of people’s time. Once out the way, you then need to look at capturing the decisions and such… which I’ll cover next post.

Advertisements
Posted in Uncategorized | Tagged , | Leave a comment

Meetings – Justify your existence

Most project meetings don’t need to happen, and those that do need to be controlled. But that is only part of the story.

By now everyone has pretty much got the message that the key to a successful meeting is to ensure that the meeting goals, agenda, preparation, documents & presentations are set up front, and each meeting should have minutes, action items, and listed follow-up. We’ve heard this ad nauseam. At the risk of inducing yet more nausea I’m going to focus on 3 points over 3 posts:

  • What most of your meetings are made up of is irrelevant, so ditch the chaff. This is the subject of this post.
  • Think about how many people’s time you’re going to waste and minimize the attendees and the agenda upfront – along with everything else
  • Keep a track of who said what. Or else…

As part of the initial planning, the project manager or team will agree with the stakeholders what meetings should take place, their frequency, attendees and so on. However, one key question should be “Why?” Why do we need this meeting? What purpose does it serve? Can it’s purpose be completed without wasting the collective time of a group of people?

We’re so ingrained that we need to have this meeting and that committee that we often forget to ask whether they are necessary and relevant. If the project is part of a larger Organizational program or portfolio then the Company Project Management Office (PMO) may have a standard list with example templates, so the risk is that even less thought is given to whether they make sense

Most of your meeting is irrelevant – fix it!

Most meetings risk descending into glorified ‘cover your ass’ sessions that cover ground that really could be better addressed before anyone comes through the door or dials in. All very useful for catching up, political posturing, appearing to be involved, and most importantly getting free coffee and cookies (if provided, and has anyone else noticed the strong positive correlation between the quality of coffee and cookies and the seniority of the chair.)

A post by Fred Kofman recently showed that by focusing all meetings on the simple premise that meetings are only needed to make decisions and to commit teams or organizations to those decisions, we can cut a lot of noise out the meetings. For one of Kofman’s clients this reduced meetings by 90%.

The only goal for a meeting is “to decide and commit.” No other objective is worth meeting for.

No meetings to “discuss.”
No meetings to “update.”
No meetings to “review.”
No meetings to “inform.”
No meetings to “report.”
No meetings to “present.”
No meetings to “check.”
No meetings to “dialogue.”
No meetings to “evaluate.”
No meetings to “connect.”
No meetings to “think.”
No meetings to “consider.”
No meetings to “educate.”
No meetings to anything but “decide and commit.”

Cut your meeting time by 90%

Let’s be clear; this doesn’t cut your preparation by 90%. All the slides, reports, charts, traffic-lights, etc. that you normally populate a meeting with need to be prepared well in advance (see the next section on the Agenda) but the sole aim is that by the meeting all attendees have a) read and digested the notes, and b) are informed enough to make decisions.

Neither does it negate discussions or networking – it’s just that this should be a separate exercise and not part of the meeting.

There are so many ways that the status of a project can be shared – from emails to shared spreadsheets to SharePoint dashboards to big visible charts pinned to a board that the meeting is possibly one of the least efficient ways of radiating information there is. The only thing that can’t be done simply without direct interaction is to collaboratively assess the impact of a strategic changes/decisions and to agree on what the next steps are – that is, to decide and commit. Leave everything else outside the meeting.

So, assuming your meeting needs to go ahead, and you can get all the relevant information out, the next step is to work out who needs to be there and then capture what is committed to – which I’ll cover in the next posts.

Posted in Uncategorized | Tagged , | 3 Comments

Creeping Death

http://geek-and-poke.com/geekandpoke/2008/6/22/one-year-in-a-it-project-day-19.html

Regardless of how well you initiate and plan the project, the journey only starts at that point as you then have to execute the work. For me the biggest risk seems to be the dreaded Scope Creep.

The PMI define Scope as the sum of the products, services, and results to be provided as a project. Scope Creep is defined as the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

For me, a far more accurate definition of scope is the outcome for which the stakeholder/client/sponsor who pays for the project is willing to pay.

So first things first; where do we draw those lines for in and out of scope? My assumption here is that we’ve already initiated the project and so a) have confirmed it is a project (temporary, defined start/stop, clear business case, etc.) – all those things we do as part of the Project Charter – and b) the time frame makes a project approach worthwhile to the company (some places mandate minimum size or duration) and the PMO has approved the project start.

Part of this start process must be to identify key stakeholders, starting with the one who will pay the bills and sign off on the Charter, etc. Next we identify the key players, and types of groups of users. If one of these groups are large in number (eg. a floor of traders) then select at least one person who can speak for them and get them on your list.

At this point we run through the basics:

  • Review initial documents and project charter
  • Identify the ‘big picture’ of how the project fits into the organizational strategy.
  • Ensure you fully understand acceptance criteria. Going back to my alternative definition of scope, you need to understand what the client is willing to pay for and what is their definition of done.
  • Identify the main project constraints (dates, staff, budget, etc.) and assumptions as these start to provide clues to where the red lines and boundaries are going to be. Start with the money – how much have you got, what’s the contingency,  and how long to burn it.
  • Identify how many key stakeholders need to be actively involved in any communication you need to generate, and what level of detail they need to keep their expectations under control.

This list along with the Charter should be enough to at least outline the project boundaries and identify key milestones.

It’s at this point that we bring up change control; the PMBoK has Change Control Procedures as part of the Organizational Assets we use to develop the main Project Management Plan and as far as I am concerned the sooner we get this on the table the better.

Let’s go back to the definition of creep again; the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

Now review the definition of Scope; the outcome for which the  sponsor who pays for the project is willing to pay.

The simple reality is this; if the main project sponsor (the one who pays the bills and ultimately decides if the project is completed to satisfaction) wants feature X added to the project, then it is going to happen. What we need to agree is that if there is an impact, then the PM will confirm the impact to the change control board and if it is material to the budget the sponsor will pay for it, and if material to the delivery date the sponsor will accept it. This saves a whole lot of dancing round later on when changes happen and then people are too scared to stand up and say what the cost is.

At this point we can run through the rest of the Planning tasks and generate the schedule, artifacts, Requirements documentation, Traceability matrix, and Work Breakdown Structure and Dictionary, etc.

What is equally important is that the Project Scope Statement also clearly states what is not in the scope if there have been some discussions and items have been kicked around by the teams. Far better to have a simple statement now that Report X is out of scope than to have Senior Manager Y decide 5 months down the line that they recall clearly and categorically that you promised it was in scope.

Even in the best laid project plans, changes will come. People forget things during the initial scope, markets move, Governments change the playing field, bugs get found. Better to get a clear framework in place from the start.

Of course, the one thing all this preparation cannot do is defend you from the unknown. Once a change request is made, the tools available to you to work out the impact are fairly limited. You basically have to rely on the Expert Judgement of you, your team, and the stakeholders (generally this is all I’ve needed but the list could include professional experts, industry groups, subject matter experts, etc.)

The main requirement is to think through the change and its full downstream impact, but not too much or you can end up over-analyzing everything. Most often, Creep is introduced when we don’t fully capture and think through all those impacts, which on a complex project can be easy to do, but this is the exception more than the rule. After all, that is why we track progress.

However, by at least agreeing in principle that the sponsor will cover the cost of those changes they introduce this reduces a lot of the conversations to “the change will cost $X and delay the project going live by N weeks. Is this acceptable?” The board can then decide if the change makes sense from a strategic and cost viewpoint, or even whether it removes the business case for the project.

By getting the process out in the open and agreed at the start of the project, a clear change management process goes a long way to avoid the uncontrolled expansion to product or project scope without adjustments to time, cost, and resources – that is, it goes a long way to avoid scope creep.

Posted in Uncategorized | Tagged , , | Leave a comment

Danger, UXB. Why UX Matters

http://maltagc70.wordpress.com/2012/05/03/3-may-1942-bomb-disposal-squad-tackles-time-bomb-threat/The letters ‘UXB’ were used in the UK during the Blitz to denote unexploded ordnance, mainly 50kg to 500kg lumps of bad-tempered explosives left behind by the ‘highly civilized human beings‘ of the Luftwaffe who were trying to kill George Orwell, amongst others.

The photo to the left is UXB in reality as a soldier of the Royal Engineers is working to make safe a 500kg bomb. It was as unglamorous as it was dangerous and the many men who lost their lives playing this game of cat and mouse get scant mention and I can only think of one recent book on their work.

For many my age from the UK, the first I ever heard of UXB was from the eponymous 1979 TV series about WW2 bomb disposal: Danger UXB.

Today ‘UX‘ is now the realm of User Experience. Not belittling the work of the UXB teams on real bombs, the point of this post is to simply highlight that neglecting UX in your project can be devastating to your project and end product.

However, what exactly is User Experience, and why does it matter? In its simplest it is the human side of the application or product; if we’re building software to run on hardware, then UX is the interface to the wetware. To some it is about the User and the raw ergonomics of how they will use your application:

User Experience Design … refer to the judicious application of certain user-centered design practices, a highly contextual design mentality, and use of certain methods and techniques that are applied through process management to produce cohesive, predictable, and desirable effects in a specific person, or persona (archetype comprised of target audience habits and characteristics).
UX Design – UX Design Defined

To others it is more about the Experience and whether the users feel positive after a series of interactions with your application:

User Experience (UX) is a term for a user’s overall satisfaction level when using your product or system. If it’s a good experience, they’re happy. If it’s a bad experience, your customers don’t come back.
Fatdux – What is UX

Most UX designers (aka human-computer interaction specialists aka interaction designers etc.) balance the two needs. When done well they combine making an interface usable with the need to stop you getting lost, or wanting to launch your screen across the room. It is not simply replacing the buttons with prettier icons to make it feel new. Good UX flows and is intuitive. Want to see good UX? Give an iPad to a 3 year old (or 93 year old with no computer experience) and watch how quickly they start to find their way around. Apple have taken UX seriously for some time and it shows.

Like most things, when done well UX is almost invisible despite being the main thing in front of our eyes. And if your application is going to be in front of a lot of people then UX becomes important. And if they have different ideas about what functionality is important, then you’d better have thought that through. In a finance application traders will want a different set of functions than operations who have a separate function than risk. Each equally important, and each completely different.

And no matter how good your application, if the design sucks then as far as your customers care your application sucks. UX matters.

Good design has to baked into a product. From the very start of a project part of your quality management should consider usability. And don’t underestimate the effort needed for good UX, especially in Agile. Agile can be problematic for UX, as Traci Lepore put it:

By nature, designers are well-organized and linear people. Logical flow is something we can grasp easily. We work well within structure. We are perfectionists and want all the I’s dotted and the T’s crossed. We thrive on recognition and success. But being agile or lean goes against these tendencies and forces us to step into an uncomfortable zone.
Why Agile Is So Hard

Nevertheless, a well thought out interface can raise the profile and customer response to a product or application. A basic Mac laptop is 2 to 3 times the cost of a basic Windows laptop but they are not 2 or 3 times as good. For the same amount of coin you can get a Windows laptop that is technically head and shoulders above a Mac, but people pay a premium for the simplicity of a Mac (as long as you are happy to be corralled into what you can do) and because it just works. (And, of course, lots of great marketing combined with the Job’s Reality Distortion Field).

In short – good UX can lift a mediocre product, and can really enhance a great product … and poor UX can bury a great product into a sea of mediocrity.

Despite the double-edge of UX, it can be great fun to work out how best to flow through an interface and careful thought can pay dividends throughout the project.

After all, even real UXB teams know how to have fun…

http://www.webwombat.com.au/entertainment/humour/picfiles/bomb.htm

Shhh! Heart attack in 5.. 4.. 3..

Posted in Uncategorized | Tagged , , , | 2 Comments

ILX gets DSDM and goes Agile… maybe

ILX (ILX Group, a software Best Practice training company strongly associated with PRINCE2) have added an Agile course to their quiver. The Agile Project Management™ (AgilePM®) covers

Agile training at Foundation and Practitioner level
Accredited project management certification for agile environments, delivered as a four day classroom course that provides a thorough grounding in the DDSM Atern Agile approach.

The first thing I noticed was the ® and ™. The next thing was the DSDM (Dynamic systems development method) choice. DSDM describe themselves as “about scalable Agile delivery of projects and programmes with the right amount of governance and control that enables successful innovation.

Governance and Control‘ and ‘innovation‘ – Oxymoron? And how does that sit with the Agile Manifesto’s ‘Individuals and interactions over processes and tools.’ However, ILX run a number of certification classes so I guess running an Agile one is yet another sign of the broadening acceptance of Agile methodologies.

Going back to the DSDM page and their stated aim to provide scalable Agile delivery, this would seem to put it head on for a turf war with SAFe and their ‘interactive knowledge base for implementing agile practices at enterprise scale.‘ One thing that is obvious is that DSDM is keen to stress its Agile roots (in RAD) and has a framework that is geared to work with Scrum (see their white paper The DSDM Agile Project Framework for Scrum.) Given Scrum is either the most or one of the most popular and widely known methodologies, this is a pretty smart move.

Maybe both DSDM and SAFe will survive in a niche market, or maybe its VHS vs. Betamax again and one will win outright in the end. Although some will decry any process that has formal requirements and being ‘not-Agile’, maybe this is the price of finally laying Waterfall to rest and getting all of big business over to Agile? Also, as Ken Schwaber – a vocal critic of SAFe – is an honorary member of DSDM consortium, maybe ILX have nailed it and DSDM is the horse to back.

Posted in Uncategorized | Tagged , , , | Leave a comment