Skip to main content

Author: Andrea Brockmeier

Beware the Unchartered Project

Written by Andrea Brockmeier on . Posted in Articles. 2 Comments on Beware the Unchartered Project

An unchartered project is an oxymoron to most project managers. Kind of like the unsponsored project. It just doesn’t compute. No sponsor, no project. No charter, no project.

But take a look at the mountain of stuff on your desk. How many unchartered projects are in there? After all, it’s not like there’s a magic threshold for budget, time, or other resources needed for something to be a project.

If it’s got a beginning and an end, i.e., it’s temporary, and it’s creating something new or unique, it’s a project and it should be chartered. Look again. How many do you have?

Why wouldn’t you charter everything that fits the definition of a project? A number of reasons may be given for not getting charters for small projects, including:

  • The time spent writing, submitting, and keeping track of a charter is better spent just doing the project.
  • No one really needs to know about this project since it only affects “us.” It’s not worth raising a bunch of flags.
  • It is a hassle explaining the reasons for the project to people who just don’t “get it.”
  • We aren’t that formal around here.
  • They may tell me that we shouldn’t be doing the project. I’d rather ask for forgiveness.

Maybe this works for your organization. Maybe these under-the-radar projects don’t have any hidden costs for you, your department, or your organization.

But maybe it’s not working so well.

If, for example, you ever find yourself unable to explain how non-project work, i.e., ops, maintenance, support, etc. accounts for all the time you’re not working on projects, then maybe some of that unsanctioned project work needs more transparency.

Or if your request for additional department resources falls on deaf ears, it may be fair to ask if those who make that decision are completely aware of where your time actually goes.

If you find yourself backed into a corner without an explanation as to why you aren’t meeting project commitments, it may be time to think about chartering some of those covert efforts.

In addition, the benefit to the organization is that when all projects, including those pesky little projects, get chartered, there’s a better chance that everyone’s priorities will be aligned. It’s pretty hard for everyone to share a priority list without the same items on the list.

It may seem like management just doesn’t “get it,” but how well-versed are you in the organization’s objectives and strategic goals? If you can’t articulate that and see how your time is aligned with helping the proverbial ship get to where it needs to go, then maybe it’s a question of who is getting what.

Like everything else, the charter needs to be scaled appropriately. One page with bulleted items in a big font may suffice. What are the minimum items that need to be agreed upon and understood? Project purpose, benefits, resources needed, estimated timeline? Whatever works.

As long as there’s a place for a signature for someone to sanction your time. You just need enough to get it on the organization’s radar.

Don’t forget to leave your comments below.

Baselines – Don’t Leave Planning Without Them

Written by Andrea Brockmeier on . Posted in Articles. 1 Comment on Baselines – Don’t Leave Planning Without Them

When I ask project managers what a baseline is and why it’s important, they tell me that it is an approved starting point against which project performance is measured.

They are right, of course.  But when I ask them if they use baselines, as often as not, I find that baselining is a fundamental project management practice that is neglected by many project managers and organizations.

Lack of good project discipline or good tools probably explains why many projects don’t get baselined.  Understanding project performance and providing input into lessons learned are two obvious reasons for utilizing baselines.

One perspective about baselines, however, sheds light both on why it is often not done and why it should be. 

As the approved starting points, baselines are the definitions of cost, time, and scope against which the project will be measured and evaluated.  The source of consternation for many is that those definitions will change. Planning for most projects is a process of progressive elaboration.  Sometimes it feels like we could plan forever, because we are constantly encountering new information, gaining new understanding, even encountering new stakeholders.

So if a baseline or snapshot of the plan is what we’re going to measure against, then it’s pretty tempting to wait just a bit longer so we have a little more information and feel a little more certain about the definition of those project objectives.  That way we will be more likely to meet them and less likely to need to change them.

But consider this: The purpose of a baseline is as much about recognizing change as it is about preventing it.  In the absence of a baseline, how do we even know if what people are asking for is different than what we’ve already done or planned? 

Why, for example, do scopes creep?  Often it’s because they were never baselined in the first place. How is it that we get into these battles with stakeholders about whether or not what they’re asking for is different than what they’ve already asked for?  Maybe it’s because we don’t have anything to compare it to!

Baselines enable us to recognize change and respond appropriately.  In order to control the project, we need to know the relative size of a change request or deviation from the plan baseline.  Is it small?  If so, then maybe we can make some adjustments to how we’re executing to bring ourselves into alignment with the plan.  Is it substantial?  If so, then we know to go through a process to get approval as to whether or not we will update the baseline and manage to the new plan.

But without something against which to compare changes, we are really guessing as to whether or not it’s even a change.  That is likely to result in a creepy scope and a project manager with very little in the way of negotiating leverage.

It’s not enough to just monitor the project if we don’t have a means of controlling it.  Without baselines we can’t do either.

Don’t forget to leave your comments below.

Our Love-Hate Relationship with Rules

Written by Andrea Brockmeier on . Posted in Articles. 7 Comments on Our Love-Hate Relationship with Rules

FEATUREAug1stThomas Edison once said, “Hell, there are no rules here – we’re trying to accomplish something.”

Rules, rules, rules. They constrain us, can make us feel patronized, and conflict with our git ‘er done ethos.  But without them…sometimes we’re a mess!

I certainly felt like one earlier this summer while watching our son play his first lacrosse game. There we were on the sidelines trying to figure out what the heck this game is all about. Most of us watching were veteran hockey parents entirely familiar how things work in that game. But this was the first lacrosse game most of us had ever seen and the whole experience was more than a little unnerving.
For starters, the equipment is a little weird. 10-year-olds dressed for hockey look great on the ice. They look like athletes. 10-year-old lacrosse players look like characters created by Pixar – half Oompa-Loompa and half storm trooper.

But what was really irritating was that we didn’t know the rules. Can you move the ball on the ground with that stick or not? What exactly does off-sides actually mean here? Can you hit someone with the stick or not – ‘cause there sure doesn’t seem to be any consistency in calls from the refs. (Maybe they are on a first-name basis with the other team.)

The silence from the sidelines was deafening until someone finally screamed “Ice it!”

It was like we couldn’t even participate as spectators because we didn’t understand the rules. It was no fun!

So it is on projects. Rules help provide context for our interactions with our team. They set expectations for what’s ok and not, and define behavioral guidelines for ourselves and others.

A project environment without rules may feel liberating for awhile, but eventually, without some idea of how people are expected to behave, team members will get frustrated with inconsistencies, perceived favoritism, and lack of fairness. And that undermines trust, the essential ingredient to an effective team.

I solicited input from some of my colleagues on ground rules that have worked well on their projects and here are a few that they shared with me:

  • Include information in email header: e.g., ALERT – must read, or RESPONSE NEEDED, or FYI only.
  • Immediately report issues and risks with appropriate candor.
  • We will only communicate information outside the team that is approved by the PM.
  • We will be transparent and proactive in our communications. Issues that come up with be addressed promptly and openly with the team and project manager.
  • We will thoroughly review minutes, decision logs, and action items lists for any missed meetings as quickly as possible (or within 2 days, etc.)
  • The PM plan will be in a central repository and in a format that all can use and accessible to all team members.
  • If decisions are made while a team member is not in attendance at a meeting, they will defer the decisions to those in attendance.

Do these sound constraining or patronizing? That discomfort may only be exceeded by the confusion and irritation of not having any rules at all.

Think about your biggest frustration on project teams and how ground rules might help. Even 4-5 well-defined, agreed-upon project ground rules might be just what your team needs to get a better sense of what game is being played and how to win it.

Otherwise, they may end up feeling like ignorant spectators with very little to contribute. And that is just no fun.

Don’t forget to leave your comments below.

Do You Have Authority Over Your Project Resources?

Written by Andrea Brockmeier on . Posted in Articles. 2 Comments on Do You Have Authority Over Your Project Resources?

FEATUREJune13thNo project should be initiated without a charter or some kind of project initiating document. While they may include various topics and information, the key purpose of a charter is two-fold: 1) It sanctions the project (or phase), and 2) It gives authority to the project manager to apply organizational resources to the project.

I think most charters do a better job at sanctioning the work than they do at making clear the authority level of the project manager. I confirm this on a regular basis with project managers working on chartered project who are expected to get project work
done with resources that don’t seem to feel any sense of obligation to the project. Some PMs aren’t even sure who the resources are that may be available to them.

For these PMs, team development as a primary role of the project manager is a complete fantasy. Although I’ve never heard anyone say it, I can imagine some have thought to themselves, “It’s my job to make sure team members have the skills they need to get their work done and that they are working together effectively as a team? Are you kidding? I can’t even get a status report from these people!”

Meeting stakeholder expectations is obviously related to a PM’s ability to make use of the project resources, so I can’t think of a stakeholder that wouldn’t benefit from the PM understanding exactly what control they have.
If the charter is the key to demystifying what authority and control a PM has over the project resources, what should that look like? What elements in a charter would make PM authority clear?

As a project manager, I can think of three things that I would like to know that would provide clarity regarding what real authority I have:

  1. What obligations does a team member have to the project as well as to their function or department? Many charters have a section that provides a description of the roles and responsibilities pertaining to team members’ project work, but what about the non-project obligations? And what about other projects the team members are working on?
  2. What are the relative priorities of those departmental and project obligations? A typical day in the lives of most team members includes both project and non-project work. For most of us, the non-project work takes precedence; we have to keep the fires out and things up and running before we get to the project stuff. At best, project work is priority #2 for most team members.
  3. If a team member has a question about competing priorities, who makes the call? Or, at least whom do they ask?

Frankly, assessing these things may result in the realization that when it comes right down to it, the PM doesn’t have much control over the resources.

But I’d rather not have control and know it and be able to manage stakeholder expectations accordingly, than think because I’m the PM and the project is chartered that I have control over resources when I don’t.

The perceived or implied control over resources in the absence of any real authority will leave PMs, team members, and other stakeholders frustrated.

Project managers owe it to their stakeholders to make good use of organizational resources to deliver project success. They also deserve to know exactly what control and authority they have over those resources in order to do so.

Don’t forget to leave your comments below.

Best Practices – Priorities and Resource Constraints

Written by Andrea Brockmeier on . Posted in Articles. 3 Comments on Best Practices – Priorities and Resource Constraints

When I ask students for their biggest challenges in managing projects, they usually tell me it’s the lack of people, time, or money.  They just don’t have enough resources to get done what’s expected of them.

I don’t doubt it.  The relentless battle cry to reduce waste and increase productivity has many project managers feeling like they are expected to build a bridge over the Mississippi River with one team member and a box of toothpicks.  By tomorrow.

How much of this challenge is exacerbated by the lack of clear organizational priorities to guide how those precious resources are allocated?

Imagine this: Starting tomorrow you and everyone in your organization will be greeted as you arrive with a documented list of organization priorities.  You will be able to take this list to your cube, post it on your monitor and let it guide how you spend your time.  Presumably, the list won’t change daily, but it will likely change.  That’s OK.  The important thing is that you have it.

Each day, you will be expected to look at your list and if you have something to do on item #1, you work on that.  When you finish work on #1 or are no longer able to keep working on #1, you move to #2.  When you finish that, you move to #3.  If, while working on #3 you are able to resume work on #1, you go back to that.  Etc.

Imagine if you and everyone around you were working from the same list.  How different would your work day be?

I worked on a team for a number of years where we did this. We were collocated in a team room and in the upper right corner of the white board in our space, our our managing director listed our project priorities.

Sometimes it would change, but that was fine. That list was the compass for our collective journey.  No one ever had a question about what they should be doing. We all had a sense of how our time and everyone else’s should and was being spent.

We finished everything on that list and it was exhilarating.

How many organizations actually do this?  In my experience I only need half a hand to count the number of organizations that I know of that have such a list that is published and communicated.

I am amazed at how many people really don’t get much top-down, documented organizational guidance in terms of project priorities.  Often, project managers, functional managers, and even team members are left to come up with their own interpretation of priorities.  Those lists tend to be pretty fluid and change daily or maybe hourly depending on whose bark is the loudest at the moment.  This inevitable conflict over resources can contribute significantly to a distorted perception of how scarce the resources really are.

It’s worth mentioning here that prioritizing does not mean labeling multiple projects priority #1. Doing so, of course, means that none of them is priority #1.  Project owners do this because they fear that a designation of anything other than priority #1 means it won’t get adequate attention or won’t get done.

The opposite is true, however.  If something is priority #2, 3, or 4, you can be sure it will get done – just as soon as the items before it are finished.  On the other hand, if a project is one of several #1 priority projects, it’s anyone’s guess as to when it will get done because multiple people will come up with their own decision about how to prioritize it.  Team members, in particular, bear the burden of the resulting conflict over competition for resources.

Unfortunately, management is often reticent to come up with the list.  There are all sorts of reasons, personal and political, that go into organizational prioritization.  People often don’t realize that if all projects are given a unique number on the list, all projects will move through the cue and eventually become priority #1.  Everything gets to be priority #1 – just not at the same time.

What does your priority list look like?  Can you document it and hang it somewhere in your work space?  If not, how quickly can your manager help you with that?  How about your project team members?  Do you know what their priority list looks like?  Do they know what their project priorities are?

And if all of those lists were collected – from you, your manager, your team members, and their managers – how consistent would they be?  How certain would you be about their consistency with senior management’s list?

The project manager’s greatest challenge will always be the management of resource constraints.

Project manager’s owe it to themselves, their stakeholders, and their organizations to make sure they are working with clear, shared, and communicated priorities to make the best use of those resources.

Don’t forget to leave your comments below.