Requirements

I haven't been interviewed in a podcast before, so I found this unscripted piece to be an interesting experience, one I might do again. You have to think on your feet, interpret the questions, draw on your experience, and try not to stumble over your words. Very challenging!

As the well known saying goes: "When you fail to plan, you plan to fail!". This may seem to be in juxtaposition with the Eisenhower saying "The plan is nothing; Planning is everything!" (both quotes paraphrased), but not when you give it a little thought.

Not having a plan will always be a disaster. Expecting that the plan you create will never change is also inviting calamity. And creating a plan without the collaboration of those who commissioned the project and those who will deliver it is also guaranteed to make your project end (if it ever does and is not cancelled) in a bad space. This is the "Planning is everything" part.

So what sort of planning should you do?

Those of us from the old school often like to take a predictive approach, while those of us from the "new" school may prefer an adaptive approach. Although, as a good friend of mine recently pointed out, "Agile has been around so long now, one probably has to consider it old school!". And that is food for thought. 

Using the right tool for the job, or as Scott Ambler or Mark Lines might say per Disciplined Agile, finding your WoW (Way of Working) is what is important. 

But in the end, whether you deliver using predictive, adaptive, or something in between, the important thing to remember is that what you are delivering has to fit into the organization's strategic DNA. Hopefully in your organization projects that land at your feet do so because the executive team has decided on the portfolio of programs and projects and authorized only those to move forward, heading rogue projects off at the pass.

I hope you enjoy this seat of my pants podcast with Trina L. Martin in her podcast entitled "Trina Talk". 

https://trinalmartin.com/podcast/trinatalk-episode140/

Meetings, bloody meetings! We all remember the video John Cleese created many years back (well, some of us do, anyway), and the recent video "“Conference Call in Real Life” that is great for some big yuks. But how do you run effective virtual meetings?  

I felt prompted to write this article when I saw the many comments after a colleague posted a link to the “Conference Call in Real Life”. I thought this demonstrated that there may be a need to provide a few guidelines on how to conduct virtual meetings effectively.  Professional behavior in virtual (and, of course, in-person) meetings is the key to success.

Collecting requirements virtually is becoming more and more common as organizations try to keep costs low.  So it is more important than ever to use virtual meeting tools effectively. But it isn't all about tools.  As is so often the case, it is more about the people who use the tools.  After all, a wise man once said that a fool with a tool is still a fool.  

So, let’s get on with it, shall we?

Tips for Meeting Chairs

So, you need to have a virtual meeting.  Well, guess what?  Just a like an in-person meeting, you need an agenda.  Send it out ahead of time and ask that people prepare. Be clear about the meeting purpose and objectives. If it is a recurring meeting, allow people to make agenda suggestions in advance in case there are burning issues they feel need addressing that you didn’t think or know to include. 

When you communicate the agenda, lay out the ground rules for the upcoming meeting.  You can probably derive some ground rules from the following tips designed to help you engineer a successful meeting:

• Tell attendees you’ll be sticking to the agenda and that “other business” can be addressed at the end of the meeting if there is time, otherwise the item needs to be added ahead of time to a future meeting.
• Everyone is expected to “arrive” on time. In the meeting announcement, include immediate methods for testing the desktop sharing/presentation software that will be used so technical glitches can be identified and solved in advance.
• Provide a phone number for road warriors or those who will not be connected. Ideally, though, everyone will join via computer so they can see shared screens.
• Display action items on a shared screen. If they are not accurate, attendees are expected to speak up.
• Input is expected, but one person will not be allowed to “hog” the floor.
• For small meetings, ask people to locate to a quiet area and keep their mics on so everyone can hear what is going on. If someone is interrupted, stop the meeting until they are free again, just like in an in-person meeting when the board room door opens and someone interrupts.
• Insist that attendees use headsets with microphones. Those built into computers are not good enough – they will make you sound like a robot, or like you are in a cave, extraneous noises will be picked up and echoes may result. 
• Use a solid internet connection. If your wireless connection is flaky, use a wired connection. 
• If material is being presented for review during the meeting, ask that it be sent around in plenty of time before the meeting so it can be reviewed, especially if feedback is being sought.
• Create a collaboration site for storing meeting minutes, or if it is a project meeting use the project repository. I use SharePoint for this.
• If a formal presentation is to be delivered, ask everyone to go on mute until it is time to ask questions or make comments. This is not a time to multi-task, though. It is only to make sure the speaker can be heard.
• Record presentations and post them to the collaboration site. Make sure you let everyone know it is being recorded, and remember to click the record button before introduction of the speaker.
• Start the meeting five-ten minutes early to ensure there are no technical glitches.
• Check meeting tracking beforehand so you will know who to expect.
• Send a communication five minutes in advance to all invitees to announce that the meeting will begin in five minutes.
• Don’t start the meeting until everyone is there, or you have allowed sufficient time for laggards (I use five minutes as a guideline). Assess whether to cancel the meeting if key people are absent or not enough people show up.
• Let people know how to use the chat window, and whether you will accept private chats.  If questions and comments may be typed in their entirety in the chat window for addressing at the end of the meeting, say so.  This is an effective way in very large meetings to handle Q&A without interruption while allowing attendees to ask questions or make comments while content is fresh in their minds.
• Consider the use of cameras. They are not usually necessary for meetings where everyone knows one another.  But if there are new people, and they are comfortable with it, you can use cameras for a round-table introduction.  If they are not comfortable with it, consider using still pictures.

As mentioned above, you need to share decisions made and action items to which attendees commit during the meeting with the group. I find most virtual whiteboard tools are cumbersome, so I usually share a document using a word processor like Word or Google Docs. 

If you are an ambidextrous cranial sort who can take notes while thinking, chairing and talking, you can do this yourself.  Otherwise, ask a colleague in advance to take on that responsibility. But watch what is being typed, because it has to be accurate and reflective of what everyone agreed. 

Make note only of important items and action items that have been agreed, including who is responsible and when the item is due.  You can send these notes to meeting participants directly after the meeting.  No more creating minutes after the fact and having people disagree with what was written since they will already have seen what was recorded during the meeting.

Highly visible decision logs and active action item lists on your collaboration site are priceless.

Noise can render a virtual meeting ineffective.  Be sure extraneous noise is addressed politely and firmly. If you have to, force mute.  Occasionally, people are interrupted and don’t control the situation well, talking with the intruder and failing to go on mute. You can mute them and decide to continue the meeting or not.  You may need to use alternate means like their cell phone to communicate with them so they know they have committed a virtual meeting sin. This is the same as if someone gets up from an in-person meeting and leaves the room.  Should you continue the meeting?  Your call… maybe ask the person or the attendees as appropriate.

Having trouble getting some people to contribute? Try doing a round table about a specific issue, suggesting that each person talk for no more than a minute or two and that if they have nothing to say, just “pass”.  Some people are too shy to interject, but are happy if they have time to think about what they want say and know they will receive the “talking stick” eventually.  Start with someone you know won’t mind talking to give the more introverted a chance to collect their thoughts.

Tips for meeting participants:

• Review all materials sent in advance of the meeting and make notes so you will cover the points you feel are important.
• Behave as if you were in an in-person meeting. Avoid distractions.    Respond.  Participate.
• If you have something to say, and you can’t get a word in, use the meeting chat function as instructed by the chairperson or use the “raise hand” function if there is one and the chairperson has said it is in play. 
• Don’t hog the floor. If the chairperson indicates you are taking too much time, respect the interjection and allow others to speak. Be concise, brief, to the point.
• Don’t make noise. Be aware of where your microphone is in relation to your mouth.  Heavy breathing is never appreciated.  If you hear it and it is not you, and the chairperson is not reacting, politely, perhaps with a little humour, announce that it appears someone is chewing on their microphone, or an obscene caller seems to have joined the call.
• Be humorous. It’s alright to have fun at virtual meetings, as long as meeting objectives are met and time is not wasted. This doesn’t mean you should tell jokes.
• Don’t interrupt speakers. It is up to the chairperson to manage people who are speaking too long. If you feel the meeting is not being managed well, consider private messaging the chairperson.
• If you see anything inaccurate being shown in the shared action list, speak up, particularly if it is your action.
• Be respectful. Take notes. Ask questions. Make comments. In a few words – be fully engaged, be present.

There is a certain degree of flexibility with virtual meetings that can save time and money, and you can take advantage of easy to use features (like record and share screen) that are sometimes more difficult to do in an in-person meeting. 

Virtual meetings don’t need to be like the Virtual Meeting in Real Life video, as humorous as it is since it is so very close to the reality of those in first-time virtual meetings. Let common sense, respect and preparedness rule the meeting, and success will be yours – and your team’s. 

Did you ever have trouble meeting a goal or deadline, or manage to get something done on time, but it was, well… shall we say less than desirable quality? Ask yourself - did you know what you had to produce every step of the way to be successful? Did you know what success should look like? Maybe it was as simple as doing some maintenance around your house, or planning your family vacation. Or maybe it was something as complex as implementing new processes to meet strategic goals at your company.

When you boil it all down to the essentials, anything that you want to do that is not an ongoing operation, anything that has a defined start and end and a desired result, is a project, or can at least be treated as one. Can you relate it to a goal? Can you describe what needs to be produced each step of the way? Have you identified which person or other resource (like a shovel or a drill, or some materials) will be needed for each one? If you've been nodding your head up and down while reading this paragraph and it's not a result of falling asleep, chances are pretty good you are dealing with a project.

So what isn't a project? Officially, anything that is an ongoing operation is not. But, what if you bound an ongoing operation with start and end dates that reflect the fiscal year, or the calendar month and list the what is required to be delivered in that timeframe? Is it then a project? There is a body of thought that would say yes, and that in fact an operation could perhaps be managed more effectively if those involved in it had clearer deliverables, activities and timelines to follow.

If you do want to treat something as a project, what is a simple way to go about it? Try following the steps below.

Charter the project - Define the reason you are doing this in the first place – the “business” reason, or the personal reason, the main objectives and generally who will need to be involved. Make sure everyone understands this and is willing to do what needs to be done and define what the end game looks like – what will be in place to gain agreement that the project is finished?

Make the plan - Define the requirements and what needs to be produced (the “deliverables”) as well as the activities required to produce each item. Consider the sequence of deliverables, what needs to be produced when, and for each deliverable, the sequence of the activities required to produce it. Consider who will decide whether a quality deliverable has been produced. Define who will execute each activity and make sure you have the required resources for each one (people, equipment, materials, and so on). Consider the cost of people and materials to create an expected cost, or project budget.

Start the project and work to the plan. Periodically take time to consider how you are doing according to plan and adjust it if necessary. Engage those who will decide whether a quality product has been produced. Let everyone on the project and other stakeholders know how things are going, including changes to the plan caused by changing requirements. Will you do more, or maybe even less? Has the timeline and budget been adjusted appropriately to account for this?

Finish the project. Go back full circle. Did you accomplish what you set out to accomplish? Have you reached the goals and does everyone agree the project has delivered on the requirements you collected from the project's stakeholders? Did you learn anything that will help you perform better next time? Did you record it? Did you deliver everything on time, within budget and, more to the point, did it or does it deliver the expected value?

It doesn't matter what you are doing, if you follow simple steps like these to give some forethought up front, plan the work based on solid requirements, then work the plan, you stand a much greater chance of being successful.

Would you agree?

There appears to be a bit of split in the use of terminology in defining the scope of a project through the creation of the Work Breakdown Structure.  Some seem to take an activities-based view, as evidenced by the template on this site called Project Work Breakdown Structure Guidelines, while others seem to take a deliverables-based approach, as found in PMI's Guidleine to the Project Management Body of Knowledge, which says that creating a WBS is the process of  "... subdividing project deliverables and project work into smaller, more manageable components".  Still others take a hap-hazard approach - don't worry - we won't talk about that here. 

I have long held that a deliverables-based approach to project planning, executing and, most importantly, progress tracking and reporting is key to creating a mindset on a project that focuses not on what you have done (the "activity"), but on what you have produced (the "deliverable").  Have you seen status reports that focus on activities done last period, and activities planned for next period?  Are they effective?  How about status reports that delve into what was produced last period and what is planned to be produced next period?  See the difference?  One pulls you down into the whirlpool of things people did, often with no relation to why they did these things and what they hoped to accomplish. The other is much more concrete - what you produced in relation to the project WBS.  You can even get very black and white about these things using the done/not done approach - a given deliverable is done, or it is not done - 0% Complete or 100% Complete.  Of course, this doesn't work very well with ill-formed project schedules where a  deliverable can consume many months or even years of effort.  But if deliverables are concise, well defined and restricted to maximum effort levels, it works very well.  Or you can consider breaking large deliverables into work products, the "done/not done" of which determine an overall %Complete, and track your deliverables that way.

If you consider a deliverable to be the output of an activity, why not flip it around and relegate activities to those things you must do to produce a deliverable?  You can structure your project schedule around deliverables, and you can measure your progress based on the deliverables you have produced, or the portion of a deliverable you have produced.  This ties in very nicely to Earned Value Management, but that is another topic.

How do you define the scope of your project?  Are you an Activities-based or a Deliverables-based thinker?  Do you measure progress based on what your team did for a period of time?  Or on what they produced?