It has probably happened to you at one time or another. You’re sitting in a meeting with your boss present when an issue comes up.
You’ve been trying to resolve that issue for a week. It’s the first time your boss is hearing about it. He asks why he wasn’t made aware of the issue. If you had defined a project escalation process, he might have already heard about it.
Having a project escalation process can help guide a project manager through the decision-making process to communicate effectively to leadership to ensure that they are informed in an accurate and timely manner. It is a matter of knowing the what, when, how and why of issue escalation.
In our project based organizations, we serve in uber-diverse workgroups. Not only are our team members from many different parts of the globe, they rarely all work for the same team.
An organization may start a project with a small group of internal staff members. That internal team may consist of a contractor or two to augment the staff. They then call in a consulting group to provide expertise and assistance. That firm may have a few contractors of their own. Continue reading Including all Stakeholders→
Looking back at every project in which I’ve been involved, I’ve seen successes and failures. There are many reasons for each outcome. But I believe the reason with the most correlation is business alignment.
To align IT with the business is one of the most critical aspects of a project, and perhaps the most difficult thing to do. So how do you align it with the business in the face of such difficulty?
Do your homework
IT people tend to know IT. I know, it’s strange. But we all have our comfort zones and that’s what we focus on. Many business people are the same with business. When it comes to IT, they don’t know it. That’s somebody else’s job. Continue reading 5 Ways to Align IT with the Business→
If you’ve ever been to an air show in a major city, chances are that you’ve seen the Blue Angels perform. The Blue Angels are a flying aerobatic team. They fly six F/A-18 Hornet aircraft and perform maneuvers such as formation loops and barrel rolls. It amazes me that six jet airplanes can fly in formation in straight lines at the speeds that they fly, let alone the acrobats they do up in the air.
Imagine if one of those pilots didn’t know what direction they were they were supposed to be going. Or if one didn’t know the next maneuver. It would, at a minimum show them going in very different directions. At worst, it could result in a terrible accident.
But that’s how many businesses and their information technology departments work together. Or rather, how they don’t.
The Blue Angels work in near perfect alignment. How do they do it, while major corporations with smart leaders fail at it so often?
Why it happens – A failure to communicate
When a business organization asks their IT department to perform a project, they will hand over the requirements of that project in various ways. They may meet for long sessions of requirements gathering. They may simply hand over previously existing documentation.
Regardless of how the team gets requirements for the project, they often do not discuss them further until much later in the project. Throughout the project, the information technology team will make assumptions based on little knowledge of the business or why they wanted the project.
Components of business alignment:
A common, and well-communicated vision
Let’s consider a case study. Ann is a great baker and starts her own business as a sole proprietor. She has a specific strategic vision in mind for her business. She knows exactly what she wants to accomplish. Everything she does for her bakery is focused on that strategic vision.
She gets up early every morning and bakes all of her goods for sale that day. She works the counter all morning selling her goods. Then she spends the afternoon and evenings planning new recipes, advertising and taking care of other business activities.
After a couple of months, it’s just too much for her to do everything on her own. She hires someone to help out working the counter. She communicates her strategic vision to her on her first day, gives her a little training, and sets her on her way.
The business continues to grow. Within a year, Ann decides to take on a partner and open another store in a nearby town. Ann explains her strategic vision to her new partner, helps her get started in the new location, and goes back to work at her original store.
Over the next few months, she sees that profits from both stores are down. She talks to customers from her original store and finds that the worker behind the counter is rude and provides poor customer service. She is confused because part of her strategic vision that she communicated to her employee on the first day was to provide excellent customer service.
When she talks to patrons from her new store, she finds out that the quality of the food is poor. When Ann talks to her partner about it, she learns that she has been using cheaper ingredients in order to save money.
Ann is puzzled about this because part of the strategy she communicated to her on the first day was to provide the highest quality possible.
This is how many corporations treat their strategic vision. They spend a lot of money to develop the vision. They print it out on some plaques and posters to hang in the lobby. They announce it to every employee on the first day of employment. Then it gets nudged aside in order to deal with the urgent calls of daily business.
A corporation who spends the time to develop a strategic vision should communicate it on a regular basis. They should announce it early and often so that it is top of mind for every employee. It should drive how every employee does his or her job.
The strategic vision should be explained to every manager. Every manager should know what it means in order for them to do their job. Every manager should be able to explain the same to every one of their direct reports. It should be cascaded down each level.
A project manager starting a project should understand the company’s strategic vision and how the project’s purpose fits into that vision.
Understand how the company makes money
McDonalds Corporation is not in the business of selling hamburgers – or fries, shakes, or salads for that matter. McDonalds Corporation is in the real estate business. McDonalds Corporation owns the land and buildings of all of their stores. Franchisees lease the land and building from corporate. They then make and sell the food that allows them to pay rent to the corporation.
Certainly the corporate parent has a vested interest in their lessees selling hamburgers profitably. But that is driven by their desire to improve their rent revenues.
An employee at the corporate level who does not understand that source of revenue risks making incorrect assumptions and decisions.
A project manager starting a project for a company should have the same knowledge of that company’s source of income. Just like in the McDonalds scenario, things aren’t always as they seem. In order to manage a project that is truly aligned with the business, how the company generates revenue is an important need for sound decision making.
Understand how the project helps the company achieve that strategic vision
Once the organization’s strategy and how they make money are understood, the project manager should understand how the project is a puzzle piece that fits into the big picture.
If there is any question about how the project helps the organization accomplish their strategic vision, that should be a red flag. Has the strategy changed? Does this accomplish it in an indirect way that isn’t immediately clear? Or, is this project not aligned with the strategy?
If the project is indeed aligned with the business strategy, the project manager is responsible for understanding how, in order to make the right decisions along the way.
Score card to validate progress
Regardless of how much the business is involved with the project once it is initiated, the project manager should develop a score card that appropriately communicates status.
Like any status, it should communicate what has been completed in relation to what was planned. But it should also explain how the accomplishments relate to the big picture of the project. The score card should also make it clear how those accomplishments also align with the overall strategy.
If a project manager reports that Task XYZ was accomplished, she should be able to explain why that helps the project be successful. She should further be able to explain how completing that task makes the organization more successful.
Information technology has long been looked at as a support function for the company. Management comes up with an approach to take orders, process orders, or track orders better. They go to IT and tell them what they want. The expectation is that IT will listen to what they want, build it, hand it over, and it will work.
Instead, IT should be looked upon as a partner. The more each individual in the IT department understands the business, the more they can provide value.
Information technology is no longer an appendage of an organization that is called in “when we need a system.” Information technology should stop being an order taker and become a partner with the business.
When there is actual integration between business and information technology, business alignment will become an obsolete term. IT needs to be integrated like one of the jets in the Blue Angels rather than just another plane that is called upon when they are needed.
How much is information technology integrated with your business?
Melvin was a project manager on a software development project. On a weekly basis, he reported status via a conference call with project stakeholders that were distributed around the world. The meeting was usually a formality. Melvin sent the status report the day before to all stakeholders for them review before the meeting.
Donna, the lead stakeholder was particularly difficult at times. She had a habit of taking one small detail and turning it into a big problem. Because of that, Melvin always entered this meeting with some trepidation.
In one particular status call, he reported on a requirements review meeting that had been held earlier in the week. As soon as he mentioned the meeting, Donna spoke up, “Why wasn’t I invited to that meeting?”
There was a moment of silence as Melvin considered her question. “I thought you were invited.” He replied.
Donna had found her problem. “I was not invited to that meeting! I need to be invited to any meeting where we review business requirements!” She went on for what seemed like several minutes to Melvin. When she was done, or at least paused long enough for him to reply, he apologized for the oversight. She continued to scold him for a few minutes before he continued on with his status.
After the meeting, Melvin flipped his laptop open and looked up the meeting invitation. Donna had indeed been invited to the meeting. She did not respond to the invitation, which is why it didn’t show up on her calendar.
Project stakeholder management can be a difficult aspect of project management. Some stakeholders, like Donna, can be intentionally difficult and seem almost impossible. Others may be easier to deal with. But they will almost always have high expectations.
To be successful, a project manager needs to know how to manage the stakeholders in order to manage a project.
It is important to start the project out on the right foot. This can be most effective if expectations are set with all stakeholders on the team.
For project team members, meet with the team as part of the kickoff meeting and develop a set of team norms. This is a list of self-prescribed and self-enforced rules and regulations. Some of the rules that my teams have come up with include keeping music limited to headphones at volumes others can’t hear. If the team has flexible hours, the team may establish a window of time that everyone is present so that they know when to schedule meetings.
The expectation should also be set with team members about the project manager’s accessibility, when can they call the project manager and when should they wait or send an email.
The project team should also know what to expect throughout the project. Explain the major milestones and what you hope to accomplish at each point. Changes may occur and the expectation should be set for that as well. When the changes do take effect, let the team know how you expect to deal with those changes. If there is a change management process, this is the time to explain it to them.
Business stakeholders need to know what to expect from the project as well. Meet with the key stakeholders and make them familiar with your management style. Explain to them the purpose of the project and how long it will take to accomplish everything. They should also be made aware of your change management process.
Explain to the business stakeholders how things will occur at the end of the project. Let them know how the system will be deployed and handed over to them when everything is tested and approved. Explain any training that will take place if necessary.
Some of this should be done verbally so that it can be heard personally from the project manager. Most of it should be done in writing too so that they can refer back to it and verify things they may have forgotten.
Expectation management is a big part of managing your stakeholders and making sure they are kept satisfied.
Once expectations are set with stakeholders, it’s important to live up to those expectations. The project manager should establish a weekly meeting with key stakeholders early on in the project. While major changes may not take place every week, it is important to meet to discuss any issues, risks, and other project updates. If business stakeholders begin skipping status meetings, impress upon them the importance of meeting on a weekly basis.
An effective visual way to communicate status of various aspects of the project is using the red/yellow/green (RYG, also called RAG status for red/amber/green) format. Like a stoplight, Green indicates that everything is in “Go” mode with nothing to worry about. Yellow indicates caution. This is used when events occur on a project where there is risk of going late, over budget, or there is an inability to meet certain critical requirements.
Red should be reported when project overruns occur, or if there are obstacles preventing the team from delivering any business requirements.
The important thing to remember is that status should be reported honestly. If major risks exist causing any component to be yellow or red, the project manager should have the guts to report it. A corrective action plan should be presented with the negative status to inform the business how it will be fixed.
There is often a tendency for a project manager to report the item as green and hope that the contingency plans in place will fix the problem. No one will have to be alarmed and the problem will just go away. However, if the plan does not fix the problem, it is usually a bigger issue that needs to be reported. Business stakeholders rarely like to be surprised with statuses that go from green one week to red the next. It is much better for them to have a heads-up on any issues, even if you fully intend to fix the problem.
Reporting status of a project regularly and honestly develops trust with the business stakeholders, allowing the project manager to work with them in a more productive environment.
The project manager has the responsibility of making many decisions. But those decisions are not made in a vacuum. Team members on the project have experience and access to front line matters that the project manager may not be privy to. Including other team members in decision making is a way to brainstorm new ideas and to include information that may not have been considered otherwise.
Additionally, including team members in decision making will be more likely to obtain their buy-in. If they feel like they helped in the decision process, they will be more likely to get behind it to prove that it is a correct decision.
The project manager must also make sure that his or her decisions don’t over step the bounds of the role. There may be decisions that the business will want to be included on. If the project manager makes a decision regarding how a requirement is implemented, the business may find out late and disagree, requiring expensive rework or even renegotiating of a vendor contract.
It is sometimes a delicate balancing act by the project manager trying to determine which decisions the business stakeholders want to be a part of. Some may be hands-off, while others may want to be part of every decision.
Learning the stakeholders’ preferences and working with them will help to develop a strong working relationship.
Creativity and a Sense of Humor
Stakeholders want to work with strong, decisive, and competent project managers. But they also want to work with a human being. Project managers sometimes come from technical backgrounds. They are more comfortable with numbers and absolute terms.
But a good project manager is also creative, coming up with unique ideas that can make a project successful. Creative ways to report status to business stakeholders can help them understand how the project is actually doing, rather than a group of statistics that can be meaningless.
A project manager with a sense of humor can also endear the business stakeholder to them as well. Business stakeholders will find it hard to deal with someone who is stiff and all business. If the project manager can make light of things and create a casual environment, the stakeholders will be more likely to enjoy being around the PM and will develop a better relationship.
While a good sense of humor is a good personal trait, the project manager should temper that with the personalities of the stakeholders. If the business culture is no-nonsense, people who don’t have patience for a lot of “messing around,” it may be better to model their attitudes rather than go out of your way to make them laugh. It can backfire and hurt your chances of developing a stronger relationship with them.
Communication may be the most important aspect of managing your project stakeholders. The basis of any strong relationship is clear, concise and honest communication.
We discussed setting expectations and reporting status clearly and honestly. These are all communication skills that will help you develop a strong relationship with stakeholders.
Additionally, a project manager needs to be willing to have difficult conversations with stakeholders. If a team member is not performing well, or has an attitude problem, it is the project manager’s responsibility to talk to that individual. The meeting should be a private, one-on-one conversation. The project manager should explain the situation and state the expectations for improvement. The team member should have an opportunity to reply, but should ultimately agree to make the requested changes.
Some project managers will put off those difficult conversations, allowing the problem to fester and get out of control. Confronting the situation early is the most effective way to deal with such issues. It usually develops a stronger relationship between the project manger and the team member.
The project manager may have to have difficult conversations with business stakeholders as well. If the stakeholder is distant or uninvolved, this creates a risk to the project that the project manager must deal with.
Having a face-to-face conversation with such as stakeholder will help to improve the situation, develop better rapport, and ultimately, develop a better relationship with the stakeholder.
Working with the various stakeholders of a project can be challenging. Some are easier to work with than others. By having strong communication skills and being a good decision maker, the project manager can develop a strong relationship that will lead to success.
I once worked with a project manager who insisted on reporting projects as green in every weekly status report. There were times when he would alter an issue status or hide issues from executives to “fool” them into thinking everything was OK.
Sometimes this worked. The issue would get resolved and the executive never knew about it. More often than not, however, the issue would do one of two things. Word would get out and the executive would find out through the grapevine. Alternatively, the issue would persist or become larger giving the project manager no other choice but to report it to the executive. When either of these two situations occurred, the executive was surprised and had less time to react and make a decision. The project manager did not manage up to the executive appropriately. Continue reading How to Manage Expectations on Yellow and Red Projects→
As project managers, we all have our weekly status meetings. For some, it can be a stressful time, especially if the project is behind. For others, it becomes as mundane as going for a cup of coffee. Whatever your situation is, it is important to make sure you’re presenting a strategic project status to your executives. Continue reading 7 Ways to Make Executives Love Your Project Status→
It was strange for my kids at first. We’d be out running errands on a Saturday and I’d tell them I have to stop and buy some toys for a meeting I have on Monday.
“Toys? For a meeting?” they would ask.
We’d run into the Dollar Store or a Dollar General and find some cheap toys. Maybe some squeezy rubber toys that light up inside, or maybe some scary rubber dinosaurs. I’d fill a basket with about fifteen of them and we’d go check out. I’d always make sure to get the receipt because I would report it on my expense report.
The kids would just shake their heads. Most adults would too. But there are some legitimate reasons to bring toys to a meeting.
I manage projects in an agile environment. For those of you who don’t know what that is, for purposes of this blog post, we plan our work in four-week sprints. Every four weeks, we spend anywhere from a half-day to a day reviewing the requirements, identifying what tasks need to be performed by whom, and planning each task for each person for the next four week “sprint.”
Reviewing the requirements can take a half a day. That’s a long time for anyone to sit and listen. So I bring everybody toys for several reasons.
Creativity: When someone has a bright shiny toy it gets them thinking differently. Perhaps it takes them back to their childhood before school and work ripped all of the creativity out of them. Or maybe the sharp contrast of having a toy in a drab work environment does the trick. Whatever the reason, I’ve seen people solve problems in more unique ways when toys are involved.
Alternative to electronics: It doesn’t take long in any meeting for someone to get bored and unholster their smart phone. Perhaps they check an email they just got a notification for. Then they want to check updates on Twitter, Facebook, Instagram, etc. Before you know it, they haven’t heard the last fifteen minutes of the meeting.
I would venture to bet that most electronics use in meetings is a result of boredom. Providing toys allows people to keep their hands busy and avoid opting for the more distracting electronic toy.
Fun: Few would refute the argument that toys create a more fun environment. When a group of people have to meet for a long meeting, the mood of that meeting can be lightened up significantly with a few brightly colored toys. And toys won’t put you in the sugar coma associated with a dozen donuts.
Status symbols: I’ve seen the toys coveted. People line their cubicles and offices with the toys they’ve collected over time. The toys become trophies signifying how many of the planning meetings they’ve been through.
Good and bad toys in meetings
To be conducive to a meeting you have to get the right toy. First of all, I wouldn’t recommend spending too much. I try to spend between one and two dollars per person. You don’t need to get more expensive than that.
The best toy is one that you can do things with. Something that squeezes or is bendable is the best. Meeting attendees can bend and ply the toy while listening to a speaker without too much distraction.
Bad toys are any kind of toy that makes noise and would distract the meeting. Balls or any kind of toy that will bounce or induce people to throw around will automatically turn thirty-something professionals into a group of eighth-graders.
I have also found Silly Putty to be distracting. There apparently are just too many things to do with it. People start looking for funny papers to transfer on to the glob or they roll it into a bouncable ball (see above).
The best toys I’ve used are rubber squeeze toys that light up (about a dollar at most dollar-type stores), Wikki Sticks (http://www.wikkistix.com/), and bendable monsters with arms that twist. (Doing a Google search on “meeting toys” will find you plenty of links to companies that market to this unique niche.)
It’s probably not necessary to bring toys to every single meeting you attend. But if you plan a meeting longer than an hour where people will be presenting a lot of information or where you want to induce some creativity, I’d suggest bringing some cheap, fun, goofy toys to it.
I’ve written in the past about what makes a good project manager. One thing I’ve never addressed is a project manager’s decision making abilities – and limitations.
Managers in general need to be decisive. It shows the ability get things done when others don’t know how to move forward.
But a project manager needs to know when to be decisive and when to defer.
For instance, I manage projects in a consulting environment. When issues arise requiring a decision, it’s important to realize that although I manage the project, and am responsible for the project’s success, at the end of the day the client owns the project. Even when managing an internal project, the business customer owns the project. Continue reading Decision Making by the Project Manager→
I used to be a very scientific and data-centric project manager. I lived by the Microsoft Project plan. I thought a project was all about tasks.
The project plans I managed in those days were full of activities, tasks and subtasks. Estimates were verified and tracked to actuals. I could calculate cost variances, earned value and performance baselines with the best of them.
When it came time to report status I had it all together. At the beginning of each week, I’d print a filtered list of tasks for each team member. At the end of each week, I met with team leads to get updates on all of the tasks that were completed for the week. Continue reading Completed Tasks Do Not Equal Accomplishments→