- Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
- Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them.
- Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase.
- Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need.
- Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources.
More posts in New to Project Management
A project manager's first global project marks a pivotal time in professional development. A project with global scope offers an exciting opportunity to work with people from many different cultures and skill sets.
However, global projects also come with unique challenges. These can include large physical distances between implementation teams, language barriers, country-specific regulations and other considerations that can negatively affect your project.
To get off to a good start, project managers need to manage the differences between global and co-located projects within these essential elements:
1. Requirements: On a co-located project, there is a single set of project requirements. On global projects, it is common to encounter both global (such as quarterly financial reporting) and country (such as provincial tax) requirements. Failure to consider them can cause painful functional gaps upon implementation. Work with your project leadership team to define a prioritization scheme for both types of requirements. For example, prioritize the country requirements by regulatory mandate, business value and desired need. A prioritization scheme helps you achieve overall balance in meeting the project success criteria.
2. Estimation: A global project typically features added complexity and costs not found with a co-located project. This calls for estimation to include additional effort to manage the previously mentioned requirements, as well as cross-geography coordination. The latter can include things such as team member travel time and global communications. In addition, there can be additional costs, such as import duties on equipment, that can add to the overall estimate. To ensure good estimation, identify global and local estimation components to more accurately account for the additional complexity.
3. Scheduling: Scheduling milestones, effort and resources on global projects is one of the greatest challenges for a project manager. The first thing to remember is to include country-specific scheduling considerations, such as regional holidays and vacations. In addition, always leave room in the schedule for project risks that can arise from unstable governments, new regulations and labor disputes. Finally, be prepared for unexpected surprises from nature, such as snowstorms, floods, volcanic eruptions and other disruptions. If such an event happens, meet with your leadership team to discuss whether to reset the project schedule around the unexpected surprise.
While global projects can present some unique problems, they also can be very rewarding when managed properly -- even if a volcano erupts!
What tips do you have for first-time global project managers?
While I am not particularly new to the concepts of agile, I was looking forward to learning the extended basic agile concepts, frameworks and skill sets, and learning to apply those skills.
Surprisingly, I understood more of Scrum than I thought I would and realized I was already implementing some agile principles into my waterfall projects. Most importantly, I realized that the debates surrounding waterfall versus Scrum may just be full of hot air.
The focus of those arguments is that one approach is categorically better than the other in all circumstances. That couldn't be farther from the truth. Traditional and agile frameworks are neither better nor worse than the other. But, either could be completely disastrous for a project if applied broadly.
One of the most important ideas I took away was the idea of 'appropriateness.' Scrum is about finding the right level of planning, documentation, velocity of task output, cost and schedule -- and not just per project, but per team. It's not about what is 'best,' but what is appropriate and suitably fits the set of circumstances at hand.
I began to think that if all project managers embraced this idea of using an appropriate approach instead of the perceived 'best' approach, projects could potentially get along much better than they currently are.
I think that what is appropriate for a project could be waterfall, it could be agile or it could be a hybrid. And that would mean project managers would have to be well versed in all kinds of approaches and understand several project management languages.
At the end of the two days, and after an online assessment, I became certified as a Scrum master, but I think I became more than that. I got better at being able to identify what a project needs and what a team needs. Now, I have a few choices as to which approach is appropriate to meet those needs and ensure success.
Do you think there can be a hybrid?
Some responses were flat out rejections of using digital devices. Other responses were accepting of using technology while others are speaking.
Personally, if you are not being disruptive, I don't think it's rude to use your digital devices in a meeting. I think what's more important to note is why people are using their digital devices during the meeting.
As a new project manager, you will probably be hosting many meetings for a project. It's up to you to stay focused even if the participants aren't captivated the entire time.
As project managers in general, we should really take a good look at why we call meetings at all.
You may think you've called everyone together to get their input. But how many people did you invite? What often happens is that a few people talk at once, and several people are left out and unable to contribute.They will inevitably find a more useful way to spend their time.
You may think you've called a meeting at a good time because everyone was available on the calendar at the same time -- finally. But realistically, almost everyone has something going on before and after your meeting. Your meeting isn't the only thing occupying their attention. An empty space on a calendar really isn't an empty space.
As project managers, we need to ask ourselves what kind of meetings we are calling, what's the purpose, who must be invited and why to determine if a meeting is the absolute best way for you to impart or gather a particular type of information. The reason for calling a meeting should not be because it's the easiest way to give information or to get input.
If you do find that you must meet, consider having several smaller meetings in small spaces that engage your core audience. Invite three to five people instead of a huge group. You can even adopt the agile practice of having 15-minute stand-up meetings to encourage groups to focus and get through agenda items quickly.
Sitting in a room waiting to be engaged is bound to lose anyone's attention. If you keep your attendee list short, even if the meeting is long, there is more audience engagement and less individual downtime. Most importantly, there is less opportunity for someone to tune out because they feel no one is paying attention to them.
How do you engage team members during meetings, and do you care if they use digital devices?
Read more posts from Taralyn.
Read more about project planning.
I'm not as oblivious to my mistakes. In fact, I have made quite a few, both personally and professionally. In some cases, my gut told me I was making a mistake, but I went ahead anyway. Other times, I forged ahead confidently, only to be jarred by the sudden reality that I'd done something wrong.
This happened recently at work. I got called into the proverbial "principal, or headmaster's office" and learned something I'd done caused trouble at a sister company. Not intending to make waves, I had started a tsunami.
If you're a new project manager, it shouldn't be a surprise that you may make some mistakes. What do you do when you are called in to discuss your fallibility on the job?
I sat and listened to the grievance presented to me -- staying calm is always the best approach. I absorbed everything my organizational leader shared with me. The first thing I said was, "I'm sorry." I briefly explained my side of the story without fanfare or drama. If you can explain yourself with brevity, do. Rambling probably won't work in your favor.
I made it clear that I understood the other side of the story and guaranteed that I would be extra diligent in the future to avoid such mistakes. I wasn't defensive. I wasn't full of ego. I recognized my part in the issue and accepted the blame, as hard as it was.
My organizational leader was professional, but she also expressed her dissatisfaction and disappointment in my behavior. This was the hardest thing to hear. The importance of being able to receive harsh criticism is not touted enough. The ability to hear -- and accept -- when someone else points out that you failed goes a long way in helping you establish a fruitful project management career.
Afterward, my organizational leader followed up by saying she trusted that I had learned my lesson and would make better decisions going forward. She appreciated hearing my side because she now had full context of the incident.
Before leaving, I asked if there was anything else I could do. In my case, the answer was no, but if there are action items for you, be diligent about accomplishing them in a timely manner. Give feedback to your organizational leader about your progress.
Making a mistake as a professional is embarrassing, but most times, your career will go on. Deal with the mistake professionally and with integrity for a chance to be even better at what you do.
A CCB can be a small group of project team members who are willing to review and approve or reject change requests. Even if your projects are small, it's better to have some semblance of a CCB than to have none at all.
A CCB can help you manage the myriad changes that will come your way as a project kicks off. Your sponsors, stakeholders and project delivery team may all have agreed on scope, cost and schedule -- but it's inevitable that something will change before the project closes.
Those changes come in many shapes and will impact your project positively and/or negatively. A CCB helps you figure out which changes are acceptable to undertake, which aren't and which can be shelved.
Instead of shunning change or accepting every idea without examination, use the CCB to determine the best course of action for the project.
There will be times when members of your project delivery team have great ideas for the project, for example. After all, they're right in the mix during the execution phase and can clearly see where things could be improved. If you always shoot those ideas down, you will create strife between yourself and your team.
You may find no one comes to you with great ideas anymore. Part of a CCB's job is to listen to all ideas, carefully consider the merits, and explain to the project team (or stakeholder or sponsor) why an idea was approved, rejected or held until more favorable conditions arise to implement it.
A CCB can be more than just a repository for tracking changes and a governance tool. A CCB can show team members and stakeholders that their ideas are worthwhile and innovative, and can help foster those ideas that most positively impact a project.
What kind of CCB do you use? What do you have them help you with?
See more posts from Taralyn.
See more posts for new project managers.
If you're new to project management, you might be surprised to learn that some projects -- maybe some of yours -- do not generate any actual profits.
That can make it difficult to demonstrate how talented you are as project manager and how great your project delivery team is. So, how can you show you've created value if you cannot show revenue or profits as a direct result of your project?
Look at ROI in a different light. Instead of using profits as a benchmark, consider intangible benefits, such as cost-savings that will result from the project, or a positive swing in public relations or team dynamics
My team and I were working on a project that involved automating a conference room. A user could walk into the room, push a single button and the automation would do the rest. The project didn't generate any profit, but the feedback from stakeholders was 100 percent positive: My team had created an environment that worked as advertised and made users' work lives easier and less frustrating. And that translated to a huge upswing in stakeholder influence.
When we needed buy-in on the next project, the stakeholders were more than happy to offer support. They even understood if the project would affect them negatively (i.e. space being unavailable for use during project, or a feature being disabled for a short time). It may be hard to say that stakeholders' good graces (for example) increased by exactly 42 percent, but it's very obvious when your ability to influence them has increased. Things seem to just run more smoothly.
Have your projects generated intangible ROI? How have your project teams benefited from it?
Such a big project brings some very big potential risks. My project delivery team and I made a list of possible risks plus a list of planned responses. Should one of the risks actually manifest, we knew exactly what to do.
As you may have guessed by now, this huge project that couldn't go wrong went very, very wrong.
Our team realized one thing while planning: We know that we don't know. Irritating as that phrase is, it may keep you from ruining what would be an otherwise successful project.
We knew that even our collective genius may not be enough to avoid disaster. But rather than spend the time creating mitigation plans for unpredictable risks, we created a mitigation plan for the actual risk of not knowing what could happen.
The plan included an eight-step process tailored to how the project team operates and how we run our projects. This gave us a standard procedure to follow if trouble arose. And when it did, we used that mitigation plan. There was no need to worry. Everything was under control, even for a risk we hadn't specifically planned for.
Because of this project, my team and I still always assume an "unplanned for" risk is on the horizon. We always give our due diligence to risk management and create responses for risks we can specifically identify. But then we review our eight-step plan to ensure we're all prepared for the unknown.
Do you have a risk-management response-mitigation plan in place for risks you know you don't know?
Project governance helps make sure that a project is executed according to the standards of the organization performing the project. Governance keeps all project activities above board and ethical, and also creates accountability.
A project governance structure will also help define a project reporting system. It outlines specific roles and responsibilities for everyone involved in the project. Project managers can leverage a governance structure in their projects to help with setting project priorities.
By understanding how governance fits into the larger organization, a project manager can choose which objectives to pursue. Or, he or she can gain support to change objectives that don't align with the overall organizational goal. By monitoring governance, the project manager helps ensure his or her project will stay in tune with organizational expectations and remains a good investment as it continues in its lifecycle.
A project manager can also use the steering committees that are part of most governance structures to resolve conflicts. Because steering committee members don't work on the project on a daily basis, the can serve as fresh eyes to see what's causing the conflict and offer an outside voice of reason. They can also offer solutions on how to resolve the conflict and adhere to the standards -- while still sticking to the overall goals of the organization.
What do you think? How do you leverage governance structures?
In project management, you must detail every step needed to get the project done and the precise order in which to complete them.
New project managers may not be used to doing things this way. Work breakdown structures (WBS) and schedule network diagrams can help them in forming a project management plan.
A WBS illustrates all of the work that needs to get done to accomplish the objectives of the project, in order of importance. To create a WBS, you subdivide project elements into manageable components and keep breaking them down until you reach the work package level.
A schedule network diagram visually depicts of how all the tasks in your schedule string together. While the WBS shows you how many tasks you have to accomplish, the schedule network diagram shows the order those tasks need to happen.
Most tasks people perform on a daily basis aren't explicitly dependent on the order in which they occur. And when order does matter, we usually engage in that activity naturally.
Our natural ability to skip details and abridge processes can save us time in everyday life. But this "normal" behavior could lead to disaster on a project where some tasks must precede or succeed others. Project managers might lose an opportunity to shorten schedules or see which tasks can run in parallel, for example.
Do you use a WBS or schedule network diagram in your projects?
Once you get past the pleasantries, ask each team member what they think of the current project slate. Are there too many projects or not enough? Which projects do they find interesting? Which ones do they feel are wastes of time?
Take the time to find out how well your team thinks projects have been run in the past. You'll get your best information from the people who actually did the work. Find out what did and did not work.
Find out if your team members understand why some projects were championed and others canceled. This inquiry will show if they understand the sponsor's decision-making process. You'll also learn how far removed team members are from project sponsors (or decision makers).
Dig to see if members "get" what their role is in the implementation of projects. This shows whether they understand how they fit into the project management process and how important they are to the completion of successful projects.
These meetings don't have to be interrogations. Grilling team members with too many questions at once may put them off. Slowly uncovering your team members' perceptions puts you in a better position to refine your approach. You can also gain buy-in for your approach, especially if you've sensed some reluctance to accepting a standardized project management procedure.
When you find out how far removed your team members feel from projects and processes, you'll be able to make an impact right away. By serving as the connection between the project team and the sponsors, you not only position yourself as the "go-to" person for information -- you also become the voice of the project. You can filter information from the sponsors to team members and take team members' feedback to the sponsors.
By doing a little investigating, you may find that it's the first time anyone has listened to the opinions of the team.
And as a new project manager, showing the team that you've heard them will take you a long way.
How have you gotten to know your new team?
Many new project managers get the same feeling when they start on the job. You sit at your desk and wonder where to even begin. You've organized the office holiday party. You've planned the family vacation. Yet the scale of project management you're tasked with now is much more rigorous.
You've been here before in a sense, but not like this. Some of us had never been in leadership positions before the call to manage a project came along. Some of us have never managed other people or someone else's money. More than some of us have never formally run a project.
Project managers just starting out or with only a few years of experience may regularly feel out of place in this world of methodologies, frameworks and processes.
There are dozens of new terms to learn and discussion about which method is the best. The key is to not let the unfamiliarity overwhelm you. If you focus on what you know -- even in the face of all that you may not know -- you'll be on much surer footing as you move forward.
Go back to the basics: You know how to listen, observe and ask questions. You know how to speak to people. You know how to get information and keep that information handy and organized. You may not know what to plug into (BAC - EV) ÷ (BAC - AC) = TCPI or even what any of those letters mean. But until you find out, rely on what you do know.
Soon enough you'll be making your way around a project with ease and, in time, the unfamiliarity will start to fade. And you'll feel right at home in your new world.