Meetings Are Not Milestones

Here’s an interesting situation that recently came up. A BA mentioned to me that his project managers included each requirements meeting as a line item in the project schedule. Meeting held? Check that one off the list. Forward progress made.

How many meetings have you been to recently that surfaced more questions than they answered? Or how about meetings where a critical stakeholder doesn’t show up and so you can’t achieve the meeting objective?

And that was exactly the problem this BA had. The project managers didn’t typically track who attended or what was accomplished. As long as the meeting was held, the project schedule showed forward progress. And since a few critical stakeholders kept not showing up for the meetings, the BA would get to the end of the scheduled set of meetings but not be done with his elicitation and analysis. The critical stakeholders would eventually show up – but not until the tail end of the process – then they would provide new information and made it necessary for the business analyst to back track and revisit many of the requirements.

As a business analyst or any project professional responsible for completing a specific set of work within a pre-determined time frame, this isn’t a good position to be in.

I think the primary issue is the the project manager (with the BA’s consent) was considering meetings to be milestones. Meetings are not milestones. This idea of a meeting held = project progress was not only creating a false sense of progress but a culture that directly supported lack of stakeholder engagement. If the project schedule is going to show progress regardless of whether I attend the meeting or bring relevant information, then why engage? I guess everything is just fine and dandy the way it is.

But how do you work your way out of this dilemma? This is an area where you’ll need to demonstrate some leadership. I think it’s necessary to re-frame how we look at our work. As business analysts, we are not ultimately responsible for merely facilitating meetings or holding requirements sessions. We are ultimately responsible for discovering the problem, turning unknowns into knowns, and gaining consensus around a set of  requirements.

The milestones we measure ourselves against should not be individual sessions, but forward progress in defining the problem, defining requirements, or gaining buy-in on requirements. With this type of milestone to track against, the BA would have been able to show that while a meeting was held, since a particular stakeholder did not attend, they hadn’t really achieved consensus yet. And this could have been the red flag the project needed to get that stakeholder engaged and keep the requirements schedule on track.

And you don’t have to be a sanctioned business analyst to apply these principles to improve your meetings. Anyone can look at how their work is measured and take steps to make sure you are tracking to meaningful project milestones and not artificial ones. Pages written, lines of code, and defects found come to mind as alternative examples.

I’m going to close today with a final thought. If it’s true that meetings are not milestones, then how do we capture the value of meetings in the first place? Well, in my admittedly not so humble opinion, the business analysts shouldn’t be facilitating just any old meeting, but working meetings. And that means you do real work in the meetings. You can only do real work if you have a clear objective in the context of a problem or a project.

With this in mind, there are a few questions we should be asking ourselves before we schedule a meeting at all. They include:

  • What is the objective of the meeting?
  • How will this meeting help move my project forward?
  • What are some of the alternate possible outcomes and how will I address them if they come up?

With this sort of structure and mindset (typically brought together in an agenda), you’ll facilitate meetings that do have real project value and do help you and your stakeholders facilitate meaningful project milestones. And you’ll build a name for yourself as the person who schedules meetings worth attending.

>>Figure Out Your BA Milestones

Join us for the BA Essentials Master Class. You’ll learn exactly how to come up with a set of business analyst milestones for your next project.

Click here to learn more about the BA Essentials Master Class

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.


  1. Anita Finke says

    Actually we had this opportunity to create a project plan template, where we put in a typical project plan content. And in this case, we plan a stage which is named “Requirements elicitation”. In this stage we put tasks, like interviews, meetings, AS is situation description development and so on. But we do not put one date for each task. Each task has a period “from – to” where it should be done. We try to agree with clients that we have these periods and we do things according to a certain order. Of course, in Agile projects we have a little bit different situation. There we do not put for each task a period. Agile is divided in sprints, where we define tasks. So, actually it is not necessary to define meetings like a individual tasks.

    • Hi Anita,

      In my experience Elicitation is not a phase but something that happens throughout the lifecycle of a project or solution delivery, though you definitely do more elicitation in the earlier stages of a project.

      I do like your approach though of having windows during which specific stages of elicitation happens, knowing you’ll schedule the necessary meetings within those windows. I think you’ll still do well to define a measurable outcome of what done looks like and when you move on to the next window of activities, otherwise you run the risk of facing the same problem as if you listed meetings themselves as milestones.

  2. Thanks for the article Laura, very timely. Just as you said that meetings are not milestones but rather means to an end (I’m paraphrasing a bit here) the same could be said for requirements themselves.

    Just as we shouldn’t track the progress of projects based on how far through the series of meetings we have completed, we should resist the urge to measure progress on the amount of requirements we have documented. As you said, “the milestones we measure ourselves against should not be individual sessions, but forward progress in defining the problem” and I would add describing possible solutions. Requirements are just means to an end for that latter purpose.



Before you go, would you like to receive our absolutely FREE workshop?

(No formal experience required.)


Quick Start to Success
as a Business Analyst

By signing up, you agree to our Privacy Policy.