What is the window of opportunity?

If the building is on fire, no matter how complex choosing your route of escape might be, there is only a set amount of time that your decision will matter. If you wait too long to make the decision, it will be made for you; routes will close and all options will go away eventually. The way the universe works is that big decisions don’t necessarily come with greater amounts of time to make them. Sometimes, you have to make tough strategic decisions quickly because of the limited window of opportunity you have. And sometimes, the speed of making a decision is more important than the quality of the decision itself.

Have we made this kind of decision before?

There is no shame in admitting ignorance: it generally takes courage to do so. If you’re working on anything difficult or cutting edge, there will be times when you have no idea how to do something. Don’t hide this (unless you’re choosing speed over quality for the decision in question), or let anyone else hide it. Instead, identify that you think the team, or yourself, is inexperienced with this kind of choice and might need outside help, or more time, to think through the problem. If a leader or manager admits to ignorance, she makes it OK for everyone else in the room to do the same. Suddenly, decision making for the entire team will improve dramatically because people are finally being honest.

Should you be making this decision – who is the expert?

Just because someone asks you to decide something doesn’t mean you’re the best person to make the call. You are better at some kinds of decisions than others, so don’t rely on your own decision-making limitations. Project managers are often seen as local experts: marketing sees the PM as the technical expert, and engineering sees the PM as a business expert. But in reality, the PM may be closer to a jack-of-all-trades (and master of none). Never be afraid to pick up the phone and call the people who know more than you do about the issue at hand. At least ask for their consultation and bring them into the discussion. Consider delegating the choice entirely to them; ask whether they think it’s their call to make, or yours. If the relationship is good, it might be best to make the decision collaboratively, although this often requires the most time for both parties.

Whose approval do we need and what feedback do we want before proceeding?

The larger the organization, the more overhead costs there are around decisions. A seemingly trivial decision can become complex when the politics and desires of stakeholders and partner organizations come into play. A good test of your authority is how often trivial decisions require approvals or the formation of committees. The more processes there are around decisions, the more you must work through influence rather than decree. There are political costs to decisions that have nothing to do with technology, business, or customer considerations, and the impact of a decision includes them.

Information for this article was based on a section from Scott Berkun’s book “The Art of Project Management.”

Related posts:

1. Making Good Project Decisions – Part 1
2. Ten Characteristics of Successful Project Teams – Part 2
3. Project Communication Series: Meaningful Meetings

Related posts brought to you by Yet Another Related Posts Plugin.

So, the first part of decision-making is to determine the significance of the decision at hand. Much of the time, we do this instinctively; we respond to the issue and use our personal judgment. Am I confident that I can make a good decision on the spot, or do I need more time for this? It often takes only a few moments to sort this out. However, this is precisely where many of us run into trouble. Those instincts might be guided by the right or wrong factors. Without taking the time, at least now and then, to break it down and evaluate the pieces that lead to that judgment, we don’t really know what biases and assumptions might be driving our thinking (e.g., desiring a promotion or protecting a preferred feature).

With that in mind, here are some core questions to consider when evaluating a decision. This list can be used in the moment to help size up a specific decision, or as a way to re-evaluate your high-level criteria for sizing up decisions.

What is the core problem for the decision?

Decisions often arise in response to new information, and the initial way the issue is raised focuses on the acute and narrow aspects of the problem. So, the first thing is to ask probing questions and get down to the real decision that needs to be made. For example, the problem might be defined initially as “We don’t have time to fix all 50 known bugs we’ve found,” but the real issue is probably “We have no criteria for how to prioritize bugs.” Redefining the problem, and the decision, into a more useful form goes a long way toward improving decision quality. Being patient and calm in response to a seemingly urgent issue generally helps to make this happen. Ask questions like: What is the cause of this problem? Is it isolated or will it impact other areas? Whose problem is it? Which goals in the vision doesn’t it put at risk? Did we already make this decision in the spec or vision, and if so, do we have good reasons to reconsider it now?

What is the potential impact of this decision on the project?

A big decision, such as the direction of the vision or the technology to use, will impact the entire project. A small decision, such as what time to have a meeting or what the agenda should be, will impact a small number of people in a limited way. If it’s a long-term decision, and the impact is deep, patience and rigor are required. If it’s a short-term decision with shallow impact, go for speed and clarity, based on a clear sense of the strategic decisions made in the vision. Generally, it’s best to make big decisions early on or in a given phase of a project, so they can be made with patient thought and consideration, instead of when time is running out.

What’s the impact if you’re wrong?

If the impact is small or negligible, then there isn’t much to lose. However, this doesn’t mean you should start flipping coins. For aspects of projects such as usability or reliability, quality comes from many small decisions being aligned with each other. The phrase “death by thousands” comes from this situation, where it’s not one big mistake that gets you; it’s the many tiny ones. So, you must at least consider whether the choice is truly isolated. If it isn’t, it’s best to try and make several choices at once. For example, either follow the same UI design guidelines on all pages, re-factor all the code that uses the same API, or cut those features completely. Get as much mileage as possible out of each decision you make.

In Part 2, we’ll examine four more questions to be asked as you proceed through the decision evaluation process on your projects.

Information for this article was based on a section from Scott Berkun’s book “The Art of Project Management.”

Related posts:

1. Making Good Project Decisions – Part 2
2. Project Go – No-Go Decisions – Part 1
3. Defining Risk Management – Part 4: Risk Quantification

Related posts brought to you by Yet Another Related Posts Plugin.

Fully understand the problem or opportunity

Problems are ordinarily complex, consisting of many aspects that require analysis and insight. There’s frequently more to a problem than what’s apparent at the first look. We need to invest an appropriate amount of time to fully understand all aspects of the problem. Very often, what appears to be the problem is actually masking a bigger, more fundamental problem. Uncovering that fundamental problem is referred to as identifying the true need.

Identifying the client’s true need—the most fundamental problem or opportunity—is the first and the most important step in the entire project process.

Identify the optimum solution

The solutions we identify through our initial, “knee-jerk” response—though they might work to solve the problem—may not be the most effective. For many problems, there are multiple solutions and various approaches for carrying them out. The key to effective project management is to determine the best solution—the one that’s most attractive to the organization. This requires some careful thought and the development of criteria by which we can evaluate which solution is “best.”

Fully develop the solution and a preliminary plan

When a solution is identified, it’s typically characterized in one or two brief statements (install an additional production line, for example). This solution statement must be converted into a plan. The process begins with a full description of the solution, including the methods for achieving it. It ends with the development of a credible, detailed project plan that the team can use as a map for execution.

Formally launch the project

The activities involved in the formal initiation of project execution depend on the organization’s specific project procedures. Project launch activities may include preparing a business case, making formal presentations to management, creating and approving a project charter, and securing funding to proceed. It also should include team-oriented activities, such as conducting a kickoff meeting and establishing mutual expectations between you and your project team.

This article was based on information derived from Gary Heerkens’ book “Project Management.”

Related posts:

1. The Need for Formal Project Change Control
2. Project Go – No-Go Decisions – Part 2
3. Common Project Issues: R & D – Too Much “D” and Not Enough “R” – Part 1

Related posts brought to you by Yet Another Related Posts Plugin.

Your duties as project manager and leaders extraordinaire certainly don’t cease … they actually increase.  You’re dealing with lots of things going on at once and you’re also dealing with two separate sets of team members – yours and the customer’s – who are being pulled by their respective organizations to free themselves up for new and exciting projects.  They’re working in shutdown mode and it’s difficult to get the productive hours out of them for YOUR project right now.  It can take all of your resource management skills just to keep team members engaged.

Customer Issues

• Complete all deliverables
• Install and test deliverables
• Prepare operating manual
• Prepare maintenance manual
• Train customer’s personnel
• Agree on level of follow-up support
• Conduct formal acceptance review with customer
• Verify customer satisfaction

Organizational Issues

• Summarize learnings – communicate to the organization
• Prepare final technical reports
• Evaluate project performance
• Conduct final review with management
• Prepare project historical files and place in archive

Personnel Issues

• Recognize/reward team performance
• Write performance evaluations for project team
• Assist in reassignment of project personnel

Administrative/Other Issues

• Dispose of leftover project material
• Close down temporary site operations
• Submit final invoices
• Forward all final payments
• Close out project charge codes and work orders

Summary

This is merely a generic list.  A true project completion checklist would need to be tailored to your specific project and each industry is going to have different things that need to be included in the checklist.  And several items are really just follow-up to things that should have been agreed to long ago with the customer, such as “agree on level of follow-up support.”  That was likely set in stone during kickoff or project planning sessions.

As always, keep the project schedule maintained – likely using something like Seavus Project Planner and Project Viewer or a similar tool.  If your project closure activities are massive – as they can sometimes be on government contracts, they may even warrant having their own, separate project schedule.

Related posts:

1. Facing Challenges at Closing Time
2. Project Phase 3 – Design
3. Managing Offshore Development on an IT Project

Related posts brought to you by Yet Another Related Posts Plugin.

Now you’re almost ready for implementation, and post-deployment activities and things are becoming harder to control.  Why?  This should be the easy part, right?  I call this the ‘Steve Blass Syndrome’ of project management (after the 1960’s and 1970’s Pittsburgh Pirates pitcher who was very good and then suddenly couldn’t get the ball over the plate – ok, so maybe I’m the only one who remembers him….).  So why would things suddenly become difficult so close to the end of successful project?

Here are a few reasons why this is often the case…

Technical Challenges

• Start-up problems with new products or new designs
• Thorough identification and agreement on all remaining deliverables
• Loss of control of the charges to the project as things are winding down – people start doing ‘whatever it takes’ to get through the final push often damaging the project budget
• Hand-off issues in transition to tech support

Project Team Challenges

• Loss of team functionality as some members complete their tasks
• Project team members become heavily involved in startup activities on new projects
• Loss of interest in tasks such as documentation and administrative work
• Fear of no future work – team members and consultants may drag their feet

Customer Challenges

• Agreement on what outstanding commitments still exist
• Absence of a clear hand-off strategy
• Change of responsible personnel at critical transition points
• Unavailability of key personnel
• Difficulty agreeing on signoff on remaining punch-list issues

That final push should be easy but it isn’t.  This list probably isn’t all-inclusive – in fact I know it’s not and I welcome your thoughts and input on this.  From my experience on projects that final push has become the most difficult when a few remaining issues exist.  What looked like a day’s work to resolve minor outstanding technical issues can sometimes becomes weeks full of effort trying to go to an agreed upon stopping point.  This is often due to the customer feeling like they’ll be left out in the cold if they agree to signoff and allow implementation with anything left on the table in terms of issues.

Likewise, there can be billing issues that remain outstanding and keep a project from coming to a swift and happy implementation and shutdown.  Vendors are apprehensive about deploying the final solution if there is a hint that they might not get paid very soon for final efforts.

There are a number of reasons and it’s sad that it can have such a momentum-sucking affect on the project and both teams, but it’s a reality.  The only solution is to keep moving forward, work closely and cohesively with your team and customer and listen to concerns.  Keep personnel motivated and focused on finishing off THIS project so you can release them for their new projects.  Keep the customer and their team engaged so that all final signoffs and handoffs can be successfully accomplished.

Related posts:

1. A Project Completion Checklist
2. Project Managers’ Top Ten Challenges
3. Closing Out the Project – Part 3

Related posts brought to you by Yet Another Related Posts Plugin.

The same thing can certainly apply to a project. Conditions can change in such a way that the project ceases to become the winner it seemed to be at the outset. Simply stated, management no longer expect the project to have the business impact required to make it wise to keep spending money on it. In many cases, a project such as should be terminated, though in far too many cases, it isn’t.

There are at least three reasons why early project termination usually doesn’t occur, even though it should:

Plodding ahead

You should be testing project viability—or financial justification—on a continuous basis throughout the life of the project. Some organizations don’t do this very well. Others don’t do it at all. Once management approves a project, it simply moves ahead until it’s completed. In today’s fast-paced and constantly changing world, it’s always possible that there will be changes that undermine the original business case for the project. That means that you need to reconsider the economic viability of every project periodically. And the organization should terminate projects that have lost their business case underpinnings.

Fear of Failure

In many people’s minds—and in many of the organizations I am familiar with—early project termination is linked with failure. This really shouldn’t be the case. Early project termination (for the right business reasons) can actually be smart management. It’s really just a process of reallocating funds from a relatively poor investment to a relatively good one. The leaders of the project, however, take it personally.  If you’re the project sponsor, executive with the idea, or the project manager, it’s hard to separate yourself so easily after having invested so much money and time and effort into an engagement.

Pride of ownership

Once a project is underway, a certain amount of “inertia” is created by the work that has already gone into a particular project. Pride swells, and a feeling that “we must see this thing through ’til the end” begins to take command of peoples’ minds. Unfortunately, it can dull them to a point where judgment is impaired. Even though a team (or organization) senses that a project is on shaky ground, emotional issues such as not being viewed as quitters, and finishing what we started, seem to become part of the process of determining whether or not to terminate the project. Couple these feelings with the sweat equity that’s been invested, and under these circumstances the project is almost certain to continue even when it doesn’t make sense any more.

The earlier the better

Normally, there should be no shame in canceling a project that’s already underway.  The only exception occurs when the project was originally initiated in a flurry of excitement, or was launched for the wrong reason in the beginning, and someone is just now getting around to figuring out that it’s a loser. The sooner a bad project is killed, the better—from the standpoint of wasted time, money, and resources, at least. That’s why you should perform business cases as early in the project life cycle as possible.

This article is based on information derived from Gary Heerkens’ book “Project Management.”

Related posts:

1. Improving Requirements Quality with Use Cases
2. Startup Project Management
3. When Project Funding Hits the Wall

Related posts brought to you by Yet Another Related Posts Plugin.

As I read further in Mr. Heerkens’ book “Project Management,” I came across his list of the communication skills of the project manager.  It’s an all-encompassing list.  It’s his list for of the abilities – in terms of communication – that all of the successful project managers have possessed that he’s come across in his career.

As Mr. Heerkens states, developing the skills needed to effectively communicate takes time, practice, and feedback.  Here is his list for those abilities he’s witnessed in successful project managers:

• Ability to express themselves effectively in conversations with organizational management
• Ability to express themselves effectively in conversations with peers and team members
• Ability to express themselves effectively in conversations with subordinates and support personnel
• Ability to speak naturally in front of a large group
• Ability to prepare and deliver formal presentations
• Ability to speak “off the cuff” effectively
• Ability to negotiate
• Ability to write clear and concise notes and memos
• Ability to write technical reports and other technical material
• Ability to listen effectively
• Ability to know when to talk and when to be quiet
• Ability to provide constructive feedback
• Ability to foster open communication
• Ability to correct others tactfully
• Ability to gauge whether a receiver understands a message or not
• Ability to use vocabulary appropriate to the audience
• Ability to interpret nonverbal communication
• Ability to project poise and self-confidence

One of the most important ways to improve your skills is to get into the habit of monitoring and critiquing your communication style continuously, asking yourself key questions, such as the following:

In interactive conversations:

• Do I speak clearly and at the right speed?
• Do I enunciate?
• Do I project my voice appropriately (not too loud or too soft)?
• Do I offer others sufficient opportunity to respond?

In oral presentations:

• Do I speak with confidence?
• Do I have any distracting mannerisms?
• Do I offer sufficient opportunity for reactions or questions?
• Do I use media appropriately?

In written correspondence:

• Is my choice of words clear and unambiguous?
• Does the message flow in a way that others can easily follow my train of thought?
• Do I avoid the use of slang and colloquialisms?
• Do I use correct grammar?

It’s ok to look to your project teams and even your customers for feedback on your communication abilities and style.  Look at it as your own personal lessons learned at the end of a project.  Give them a chance to critique you and do it with confidence.  You led the project and what they tell you can only help you to be a better project manager on future engagements.

Related posts:

1. Project Communication Series: Project Schedule
2. Skills of a Successful Project Manager
3. Project Communication Series: Customer Interfacing

Related posts brought to you by Yet Another Related Posts Plugin.

Gary Heerkens book entitled “Project Management” covers the concept of high-quality, effective meeting communications.  Though I don’t fully agree with all of it – specifically when he discusses how you should not have a meeting if you have nothing new to discuss, because I think it’s critical to stay on schedule and at least have a brief weekly status meeting with the team and customer even if there’s little to discuss – I still think the text is interesting and worth noting here.  Please read on for Mr. Heerken’s views on this topic…

Conducting productive meetings

Meetings can be a very effective way to conduct business. They bring people together for a relatively short amount of time so that large amounts of information can be shared. As mentioned several times previously, you should conduct core team meetings regularly to promote a steady flow of information to and from team members. But you’ll find that there are many other times when you may need to call for a meeting. Meetings are a critical form of communication.

Unfortunately, many people view meetings unfavorably, in part because they feel that there are too many meetings and most are poorly run, so it can be a struggle to get people to attend. If you develop a reputation for running effective, no-nonsense meetings, you increase your chances of consistently getting team members there to conduct business. Understanding when to call a meeting and learning how to run one are key skills that do not get sufficient attention in many organizations.  Here are some tips about calling and conducting meetings— core team meetings as well as general meetings.  Determine whether a meeting is even required. You can avoid being viewed as “meeting-happy” if you follow these basic guidelines:

• Don’t call a meeting if a series of phone calls will serve the purpose.
• Don’t call a meeting to decide something that you can or should decide.
• Don’t call regular team meetings any more frequently than necessary.
• Don’t call a meeting if you’re reasonably certain there’s nothing new to discuss.
• Don’t prolong a meeting if the group is through conducting the business at hand.

Be clear on the purpose of the meeting. Being clear on the objective of the meeting will sharpen its focus and therefore improve efficiency. Here are the basic meeting types and their purpose:

• Progress—to assess status and accomplishments and to set more goals
• Decision—to develop and agree upon a decision
• Agreement—to present a case on a decision and seek collective acceptance
• Information—to communicate information or decisions that have been made
• Opinion—to collect viewpoints and perspectives from participants
• Instruction—to provide direction, enhance knowledge, or teach a skill
• Review—to analyze some aspect of the project, such as design

Related posts:

1. Project Communication Series: Planning Meeting Agenda
2. Project Communication Series: Project Schedule
3. Project Communication Series: Customer Interfacing

Related posts brought to you by Yet Another Related Posts Plugin.

Along with the status call and the status report, the project schedule is a form of communication that needs to happen on a regular basis every week.  Just like team meetings and customer meetings that become irregular, if you stop producing updates to the project schedule and delivering them to you team and your customer, they’ll never feel confident that they know the current status of the project.  They won’t know if what you’re delivering to them is accurate and current, from last week, or just a best guess.

This goes back to earlier things I’ve written on project management characteristics and being organized and doing what you say you’re going to do.  In the project kickoff meeting or during planning sessions on the project, you hopefully set team and customer expectations on the communication aspects of the project.  Hopefully, you even produced some semblance of a Communication Plan that documents when you’ve agreed to produce regular communication documents and hold specific meetings.  The key is to adhere to those as much as possible throughout the project.

By doing what you said you would do, by adhering to the plans and schedules that were documented and agreed to with the customer early in the project, you build a huge amount of trust and confidence with the customer in your abilities to manage their project and to be reliable.  So, back to the project schedule.  There is an incredible amount of detail in that schedule if you’re using it to it’s fullest potential.  By producing regular updates and delivering it at the same time every week, you build confidence in your team, your customer, and your company leadership that you know what is happening on your project, here is the latest status, and you’re in control.

Here’s my suggesting for using the project schedule during a normal project week:

• Review notes from last week’s project status meeting and update the project schedule accordingly
• Have a internal team status call (do this weekly on the same day every week)
• Use the team information on task updates, issues, etc. to revise the project schedule.  Whatever software you’re using, use it effectively.  I recommend an easy-to-use and full-featured tool like Seavus Project Planner and Project Viewer.
• Deliver a revised project schedule with the weekly status report at the same time every week – preferably about one day in advance of the weekly status call with the customer
• Hold the weekly status call and use the project status report and the project schedule as drivers for the communication on the call

Summary

Having an up-to-date project schedule in the hands of your team and customer every week in advance of the project status call can definitely help your status call be more productive.  And your customer will have solid confidence in you that you and your team are on top of things and in control of the project.

Related posts:

1. Project Communication Series: The Project Status Report
2. Project Communication Series: Meaningful Meetings
3. Common Project Issues: Budget Overrun

Related posts brought to you by Yet Another Related Posts Plugin.

Just as important as the project manager’s communications with the customer are the individual project team members’ communications with that same customer.  The part that becomes hard is that as the project manager you’re responsible for ALL communication, but you can’t always police that which you are not a part of.  Nor do you really want to, but it does all come back to you.

So the questions then become:

• How do we (the project manager) best interface with the customer
• How do we prepare our team to interact with the customer
• What actions do we take to oversee all communication
• What do we do when the communication goes wrong?

Project manager – customer interface

The primary function here is to practice frequent and effective communication with the customer.  Most of this done through the creation of informative and accurate weekly material: status reports, project schedules, issues and risks tracking sheets, status calls, and status call notes among other things.

But even the informal communication with the customer is important and must be done with care.  Always be above board with the customer, but also always be above reproach.  You don’t ever want to spread gossip, give inside information that is not appropriate, or speak poorly of your team, your company, the project, or customer personnel.  Always maintain a very high-level of professionalism.  It’s ok to be familiar with the customer, but don’t let your guard down … they’re still the customer.

Prepare the team

At the beginning of the engagement set the ground roles for the team in their communications with the customer.  Coach them on professionalism, the methods that are acceptable, and what communication approaches to use in different situations.

One more thing – in this age of social media – be sure to make it clear that no discussions with or about the customer should happen on Facebook, Twitter, Myspace, Google Buzz or any similar source.  During the project that is too familiar and potentially unprofessional.  And once it’s out there, it’s there forever.

Overseeing the communication process

This one isn’t easy because communication is happening all the time and you can’t oversee everything.  Make it clear to the team that decisions need to involve you and most need to come from you.  In fact, all official project communication needs to come from you.  However, you don’t want to slow progress, so ask that you be cc’d on all important project communication that doesn’t require your immediate attention.  Stay in the loop because when things are moving fast on a project, once you are out of the loop it’s hard to fix what might go wrong.

Fixing the mess

This exactly where you hoped not to be, but it happens.  And you may have a mess to clean up or fix.  Go back to the effective communication and the practice of full disclosure with the customer.  Making them part of the solution rather than keeping them uniformed is almost always the best way to go.

And for communications that get out of hand … that’s a another problem.  First, go to the source.  If it’s your team member, then discuss the communication issue with them and understand their side of the story.  Then take it to the customer together.  Working with the customer and the team to proactively correct a communication problem or misunderstanding will show that you’re involved and the problem is being addressed.  This will go along way in maintaining customer satisfaction and confidence.

Summary

Communication happens throughout the engagement and without effective communication a lot can go wrong on your projects.  Poorly communicating one important requirement can cost tens of thousands of dollars – more if your project is huge.  It’s critical that the project manager is in charge of all communication, preps the team on effective communication and keeps the customer as well informed as possible in order to help ensure a successful project.

PMtips.net is proudly supported by ProjectOffice.net.

Related posts:

1. Project Communication Series: PM Communication Skills
2. Project Communication Series: Planning Meeting Agenda
3. Project Communication Series: The Project Status Report

Related posts brought to you by Yet Another Related Posts Plugin.