- 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 PM Think About It
Mr. Scalia simply replied that he didn't worry about that. He has life tenure, given to him by the U.S. government. He believes that tenure allows him to do and say what he thinks is right and not worry about how it will affect his career or colleagues.
This answer had a profound effect on me. I often wonder if I am "doing the right thing" when I make decisions at work. I try, but I would not be honest if I did not admit that the career survival instinct hasn't kicked in once in a while. Perhaps sometimes I compromise on issues that I know are not good for my projects or my team. But I'll give the client the answer they want to hear, or perhaps tone down the weekly status report to avoid stirring the pot when there are real issues to discuss.
I've now started applying what I will refer to as the "life tenure" rule to all of my decisions and activities. I try to look at a decision or situation through the lens of "If I did not have to worry about politics or personalities or self-promotion, would I still make this move?" I have to say, thankfully, that I appear to achieve that about 90 percent of the time. But clearly I think that can improve.
I know it is naive to think that someone could or should perform their job as if they could not get fired. Or to think that if we all had that freedom, that we would always make the right decision. But it is an interesting concept to ponder, and a fascinating test to apply.
Think about it: How would your professional life change if you had life tenure as a project manager?
What was different about the projects were the dynamics between the client and the project team -- specifically, the way the client engaged and worked with the project team. One project was successful, and the other was not.
In my opinion, the success as well as the failure was largely because of the dynamics between the client and project team.
I am definitely not implying that any project gone awry is the client's fault. In fact, I believe it's the project manager's primary responsibility to facilitate all points below. But unless the client is willing to observe and adhere to these guidelines, the project is already in jeopardy.
Think about it.
Here is a working list of guidelines that can help clients and other stakeholders work with a project team and deliver a successful project:
1. Be transparent. A good project team realizes there are going to be unique variables and circumstances it will need to address. Be upfront and candid with the project team about the challenges or risks in accomplishing the project goals. It is much more productive to get everything on the table upfront versus waiting for it to be discovered while executing the project.
2. Stay engaged and responsive. One school of thought says a good client stays out of the way of a project team and without too much micromanagement. This can be true to some extent.
However, clients must work with the project team to ensure there are open channels of communication. Information or clarification must be provided quickly and concisely, and preferably in writing.
Ideally, one or two people on the client side have the knowledge and authority to speak for the entire client team. This is especially important when providing critical input such as requirements, milestone approvals and strategic guidance. Without this representation, the project team has to chase down information, and there is greater risk of them getting it wrong.
The project manager must facilitate these activities and provide the framework in which they occur, but this is a two-way street.
As a client, if you cannot make the time and emotional commitment to communicate, then postpone the project until the time is better. Otherwise, we all risk having to do it over again.
3. Be decisive and time sensitive. Recognize that there are going to be hard decisions to be made in terms of requirements, tradeoffs, budget, timing and resources. If a decision cannot be made on the spot, define a window of time in which you will get back to the team with an answer and respect that commitment. As noted above, if it's going to take time to get an answer, let the project team know this ahead of time.
4. The laws of physics still apply. As nice as it would be to bend the laws of physics, project teams are not capable of making three-day tasks in just two. Project managers do sometimes pad their timelines to allow for project creep or addressing other unseen emergencies. But recognize that this is done due to experience from previous projects and is an effort to account for the "unseen" challenges that inevitably crop up in your efforts.
Forcing a team to schedule its project activities in exacting increments for the sake of impressing company executives, for example, introduces a risk that some unforeseen event will cause that project to run late.
What other guidelines would you add to this list?
Read more from Geoff.
Today, the fastest rising communications and computing technology is mobile. And while this development provides exciting possibilities for improved project efficiency, it does not come without risks. I'm focusing specifically on devices with a mobile operating system, such as iOS, Android, Windows Phone 7, Blackberry or Nokia.
The reason for my concern is the speed of adoption for the devices. They now play a role in every project I manage. It may be simple communications such as email between team members, text messaging and calendar functionality, or more sophisticated uses such as remote access to project data, project management software or even video conferencing. Yet 90 percent of the time, I find that no one is really thinking through the implications of using this technology.
Think about it: With this expanded communication comes an increased risk that your project's confidential or critical information could be exposed, intentionally or unintentionally.
This information can be controlled fairly easily by IT departments on laptops, but mobile operating systems don't allow for the same kind of security just yet. You must be wary of how information may be getting communicated over your mobile device.
Information "attacks" can come in several forms. At an event where "free wireless access" is offered, for example, someone who wants to gather data illegally can set up a US$50 wireless router, name it "[Event Name] Wireless" and watch as attendees innocently connect their devices to communicate with the rest of the team. Simply leaving your Bluetooth enabled in public locations can open you up to attacks.
It doesn't even need to be something that devious. All that needs to happen is for one of your team members to lose a device that has regulated data on it. In the United States, you'll have to officially report the incident to the Federal Government.
The key takeaway here is that as our world expands, we are being given exciting new ways to coordinate and communicate with our team members across the planet. We should take full advantage of this. But we should do it with our eyes open.
How do you protect your data on a mobile device?
I'm sure many of you heard about the Boeing 787 Dreamliner that made its first commercial journey on 26 October. It is the most technologically advanced commercial airplane and enables air travel that is cheaper, faster and more comfortable.
Perhaps you also heard about the process, communications and quality issues that delayed the project by three years and cost the company close to US$10 billion in overrun charges, according to the business news outlet Bloomberg.
As a project manager, what jumps out to me is the fortitude of Boeing's management to ensure a quality product -- despite extraordinary pressure.
I have no doubt that if it had wanted to, Boeing could have completed this project earlier. But rather than take shortcuts and risk potential issues, it held out for a product that met its standards.
Much attention has focused on Boeing's attempts to save money and to secure global accounts by outsourcing a large portion of its component manufacturing and design. The idea was that assembly and time to market would be accelerated by allowing various parts of the plane to be flown to Boeing's facility in Seattle, Washington, USA. There, they could be pieced together in order. According to news reports, the move initially netted Boeing nearly 1,000 orders and helped keep its prime competitor, Airbus, at bay.
But it marked a big change in Boeing's existing process to keep almost all of its engineering design in-house. The company typically delivers very specific "build-to-order" instructions to its manufacturing partners, outlining specifications and direction, and then collaboratively designing the parts.
There were many challenges associated with a project as complex and pioneering as the Dreamliner project. One example is the process for oversight and quality control of multiple, globally based contractors. Issues arose, such as contractors subcontracting to suppliers who couldn't meet deadlines or quotas. In other cases, contractors shipped parts that wouldn't fit together correctly.
Think about it: In my opinion, Boeing realized that it was more important to get the project done right versus done fast. And while the company has faced criticism, suffered some embarrassment and, yes, spent more than it anticipated, these are all short-term issues.
In the long run, I believe the project will bolster Boeing's reputation for quality. It will also have finely tuned a project management process that should bring the company much higher returns in the future.