Trust button set on highest position. Concept image for illustration of high confidence level trusted service or review.

Is Your Boss Trustworthy?

This may seem like a simple question, but the answer is bigger than we think it is. We’ve all grown somewhat immune to the mocking of those in charge – you see the President of the United States and other world leaders mocked on TV and other media all the time. But really, what about the leadership of your company? Do you have confidence in them? Do you think they have your back? Do you feel like they’re leading you, your co-workers … even your customers in the right direction?

I think the answer for many of us is often ‘no.’ And that’s sad. Why is that … why do we feel this way?

Trust button set on highest position. Concept image for illustration of high confidence level trusted service or review.

Continue reading “Is Your Boss Trustworthy?”

Unknown opportunity concept as three dimensional text hidden underwater with a viral healthy tree growing on a small piece above water as a metaphor for success and motivation to search for hidden opportunities in business and life.

Do you know what the REAL project is?

Sometimes what you’re really trying to solve is a bit hidden. The customer may not see it and you might not at first glance either. But it is your responsibility to make sure you always go that extra mile to make sure you are addressing the real issue and not just a symptom that the project sponsor sees and what seems obvious to everyone.

Unknown opportunity concept as three dimensional text hidden underwater with a viral healthy tree growing on a small piece above water as a metaphor for success and motivation to search for hidden opportunities in business and life.
Sometimes there is more to a problem than what you can easily see.

It’s not always easy to truly identify what is the real project. On the surface, it seems obvious. The customer comes to you with ‘x’ need and you work with the customer on business processes and requirements and move forward with work on a solution for that customer. You have a project involves working to solve the customer’s identified need.

However, it’s not always that easy … and as the Project Manager, you must assume that the customer doesn’t always know what it is they want or even what their true need is. Identify that true need, and you’ll be building a solution that keeps the customer happy.

Get the big picture by asking the right questions

Problems and opportunities can arise almost anywhere inside or outside the organization. Problems are typically driven from within and frequently relate to improving organizational performance. For example:

Problem Solution
A department that’s overwhelmed with paperwork. Simplify procedures.
An organization that constantly faces the prospect of worker strikes. Improve management/employee relations.
An insurance company that has branch locations spread across a wide geographic region. Communicate effectively among branches.

Problems are generally regarded as negative. Opportunities may be viewed as their positive alter ego.

Opportunities are often driven by external forces. More common examples can be found in the areas of product development or product enhancement. These opportunities are often the response to a perceived need in the marketplace. In other words, sometimes a problem leads to opportunities.

Identify the true project

The term “true need” refers to the most basic problem to be solved. Identifying your project’s true need can, at times, be tricky. But it’s absolutely vital that you as the Project Manager understand what the true need is.

Why? Because many will judge you as a project manager by your ability to solve the original problem. Solving the original problem equates to satisfying the true need and you and your project team often have to dig to find out what that true need actually is. You cannot be certain that you’ll satisfy the true need unless you know what it is. The problem is that when you’re assigned to manage a project you may not be presented with the true need explicitly. Terminology can become confused: what’s described as a need may actually be the solution to a need.

One of the most reliable methods for uncovering the true need is to ask the right people one simple question: “Why?” However, as you seek to uncover the true need, you can expect to encounter some resistance.

Summary / Call for Input

If you ask questions rather than digging in and getting the project going, some within your organization may assume that you’re not moving forward. However, asking the right questions of the right people can often lead to some startling discoveries.

Readers – have you had many projects where the real need was buried and the customer was actually coming to you with a symptom? I have … and the end result would have been disastrous if my team and I had only delivered on the symptom rather than digging for the real problem. Please share your experiences.

It takes a team to develop solutions and reach goals.

Is the Project Worth Saving? (Part 2 of 2)

In Part 1 of this two-part series on figuring out whether or not what we have viable project … we looked at what brings us to the go / no-go decision point and how we review a project from both a justification standpoint and a feasibility standpoint.

Now, in Part 2, we’ll consider how to:

  • Review alternative solutions for your project’s problem(s)
  • Identify the best solution for moving forward

Project Justification and Feasibility.

Once you fully understand the project’s goal and establish that it is justifiable and feasible, you’re ready to determine the best way to satisfy that need. (You may wish to review Part 1 of this series.)

Although I’m using the term “you,” proper execution of this step really requires the input of many individuals. If you’re fortunate enough to be involved at this stage of the project’s evolution, you should be actively working toward building a team that can work with you from this point on.

Identify Alternative Solutions.

The process of identifying the optimal way to satisfy the project requirements begins with generating a list of potential solutions. This process is made easier when these elements are included:

  • Do it in a team environment
  • Include subject matter experts and stakeholders as appropriate
  • Use brainstorming techniques
  • Limit further development to only reasonable alternatives

Choose the best solution for moving forward.

Obviously, you can’t pursue every idea identified through processes like brainstorming.

After soliciting all reasonable alternative solutions, the project team needs to pare the list down to only those that are worthy of further development, investigation, and definition.

It takes a team to develop solutions and reach goals.

You can reduce the list by comparing each alternative against predetermined criteria. This is where the Requirements Document begins to add significant value. The process for selecting the optimum solution begins by evaluating each alternative solution in terms of how well it satisfies the most critical aspects of the project requirements, such as budget constraints or strategic alignment.

You may also wish to use other requirements-based considerations, such as the likelihood of technical success or the anticipated impact on existing products. This initial screening will allow you to shorten the list of potential alternative solutions to a manageable number (I would recommend two to five).

At this point, the selection process becomes much more rigorous. Each potential alternative should be evaluated using two basic types of criteria: financial and non-financial.

Summary / Call for Input

Readers – how do you feel about this process? How does it match up with your organization? Do you have similar processes you can share and discuss?

Not every project is cut and dried and definitely a project – some have to be fleshed out and decided upon … is this really something we should be doing and is this the best way? If not … what is? Please share your thoughts.

Woman says that she dreamed the answers to their problems.

Is the Project Worth Saving? (Part 1 of 2)

In one of my past lives in corporate America, I worked at a very large, Fortune 500 engineering and aviation firm that featured a central Project Management Office (PMO). There existed a requirement for all project managers to go through the following exercise on the larger projects (not all of the smaller projects required a formal process like this):

  • Kickoff the project with the customer
  • Document high-level requirements with the customer
  • Ballpark a solution and an estimate
  • Perform a formal project presentation to a technology council

Two things to understand first before going any further:

  • Nearly all projects at this company for the Project Managers (PM) were internal
  • The Tech Council was made up of internal executives

The sole purpose of the Tech Council and the PM presentations was to ensure that the project was worthwhile taking on (since everything was internal and really represented a shifting of money from one department to another rather than actual income – except where costs were being saved) and to ensure that legacy technology was not going to be used in a long-term solution when that technology was planning to be phased out and unsupported in the near future.

So, in a sense, the Tech Council was basically a go – no-go decision point early in the project. Even though it was early in the project it was a good time to ask:

  • Is this problem worth solving?
  • Does a potential solution exist?
  • Are we going about this solution in the right way?
  • Does this fall in line with our overall company goals and mission?

Justification and Feasibility

Buried in these four questions is addressing the issues of justification and feasibility. You should deal with both issues before continuing no matter what customer base you’re servicing – internal or external. If not, you run the risk of wasting time and money on problems that should not or cannot be solved.

Woman says that she dreamed the answers to their problems.

Justification.

Particularly financial justification—is very difficult to assess at the requirements stage, because not much is really known about the project. Nonetheless, it’s wise to try to assess whether or not you can justify continuing the project. You may be able to do this by executing a simple cost vs. benefit analysis.

The benefit component is relatively easy to estimate: it’s the value of satisfying the need. In many cases, this is nothing more than calculating how much the problem is costing today. Estimating the cost of the solution is more difficult, because you’re not sure what you’re going to do or how you’re going to do it. One approach you may wish to consider consists of working backwards through the financial calculations. By doing this, you can determine the most you’d be able to spend on a solution. If none of your proposed solutions can be executed for less than that amount of money, the project will ultimately be unjustifiable—at least from a purely financial standpoint.

Feasibility.

This comes down to a basic question: Do you believe that a solution exists? In other words, can this problem even be solved? This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

This step is referred to as verifying feasibility. There can be much subjectivity in this step; you should rely heavily on the judgment of subject matter experts (SMEs). In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

In reality, the most that you can realistically hope to determine at this point is that the possibility of a solution is thought to exist. That’s OK. As with justification, all you’re trying to do at this point is preclude the expenditure of additional resources and money on problems that have no reasonable solution.

Summary / Call for Input

In Part 2 of this two-part series, we will look at working to identify the best solution possible for the project need and whether it is feasible to proceed with the effort.

Readers – please be thinking about your own processes that you and your team or management go through to make project go / no-go decisions and be prepared to comment and discuss.

Row within Row Milestones have task dependancies

Creating Recurring Tasks within a Project

Schedules are living documents, so oftentimes we need to review them regularly to look at what has been done so far and make changes to what still needs to happen. One of the easiest ways to do this is to hold reoccurring weekly meetings.

FastTrack Schedule makes it easy to pick each specific date and time that our recurring tasks will happen, we can even create dependencies to and from these meetings to show how they interact with the other portions of our project.

Create Recurring Tasks

For today’s example, we will build a recurring task to represent our weekly status meetings. When we enter our task, we will create a zero-day duration to mark it as a milestone within our project.

  1. Input the Activity Name and initial Start/Finish Date for your initial meeting.Zero Day Duration
  2. Add a new row for your next meeting date:
    • Place your cursor after the Start Date (11/15/12) for our “Status Meeting” task
      – Windows Users. Hold down Alt and press Enter.
      – Mac Users.       Hold down alt/option and press Return.
      This will create a new line for data within the current row.
  3. In this new row, we can select the next specific starting date, whether it is on the same day of the week or a different day completely, for our Status Meeting.New Row within the Row
  4. You can repeat the above process as many times as necessary to show each occurrence of this Status Meeting during the duration of your project.Multiple rows within the row

Change Vertical Alignment of Recurring Task Milestones

Once we’ve created numerous meeting instances, you will notice that each milestone on the Timeline Graph will line up directly with its corresponding date in the Start/Finish Date column. If you prefer, we can change this behavior so all bars appear on the same, centered line.

  • Windows Users. Right-click or Control-click any milestone and choose Select All.
  • Mac Users. Right-click or Control-click a selected milestone and choose Align to Grid.

This will align all of your milestones to the grid of the row, which by default matches the alignment of the row number.

Row within row vertical alignment

Create Task Dependancies

We can also create dependencies between our tasks to show a realistic flow from meeting to meeting, and any steps that may occur in between.

Milestones have task dependancies

Contribute to the Conversation

Have you ever had a project where you needed to show recurring tasks, but entering each of them into a new row was too cumbersome and clustered to view? In your upcoming projects what are some ways you can make use of recurring tasks to better show the flow of tasks?

Finger-pointing, placing blame on someone else.

Handling the Blame Game

A reader of one of my articles recently commented about people blaming others for failures on projects and workplace tasks. We all know he’s right … some of us may have been guilty of it ourselves once or twice … or had the finger pointed at us in the ugly blame game. But that isn’t very professional and it still won’t resolve the issues with the failed or failing project – something still needs to be done no matter who’s fault it is. Let’s look at the whole blame scenario and how we might react and resolve the situation.

Finding someone to blame the bad stuff on.

The reader states that some PMs have a tendency to blame everyone and everything else when things go wrong. He says that all too often he see PMs blame others (suppliers, team members, customers) or things outside of the project (like the economy or the weather or even the exchange rate).

Finger-pointing, placing blame on someone else.
He’s right. There are people in organizations – not just PMs – that do this all the time. And there are PMs – the ones in leadership positions on projects – who are pointing the finger constantly at team members and customers, often just to make sure that they still look good when it hits the fan.

Look in the mirror.

Continuing on, the reader states in his comment that a good PM looks in the mirror first and should be the first to admit the mistake. I agree completely, though admitting mistakes is very hard for some. As the PM, we’re in charge and everyone is looking to us for our leadership. The PM must be in charge and must be ready to take charge and certainly must be ready to take responsibility for things that happen on the project.

I’m not stating that a PM should take blanket responsibility for every bad thing that happens during an engagement. Not at all. Rather an approach of ‘let’s see what we can do to get through this issue together’ is a good course when the problem was obviously caused by something beyond the PM’s control. The PM should not be a martyr taking on all blame no matter who was responsible. Nobody really likes a martyr who takes the weight of everything on their shoulders, but nobody in their right mind is going to follow a PM who finger points when issues arise. No good comes from it and no problems are really solved by it … all it serves is to divide the team and that is a recipe for disaster.

How do you deal with this type of leader?

First, personally, don’t become one. Have you ever found yourself easily pointing the finger at someone else – even privately among your team members? I have, and I hate myself for it later. It can also be detrimental to your leadership position with your team members – if they see you as a finger-pointer in the blame game, then they will not be seeing you as the take-charge leader you need to be.

How should we deal with this type of behavior when project problems or failures arise? Here are my first thoughts…

  • Re-direct the discussion from finger-pointing to aggressive resolution (if you’re not part of the solution, you’re part of the problem).
  • Have an offline conversation with the offending individual about the negative aspects of that type of behavior and its effect on the rest of the team.

If the private discussion doesn’t have the needed effect on the team member, then take it to their manager and ask that they be reassigned and replaced on the team. Stop the cancer before it spreads to the rest of the team.

Call for input

Project managers and project team members … have you seen this in your workplace? I’m sure you have at some point. Was it on your project? How did you deal with it? How would you deal with it? Please share your own experiences and let’s discuss.

Business team of success pop art retro style. The joint work. Business success. The schedule of growth. the business staff. Firm

PM Oversight of the Project Delivery Team

One key aspect of the responsibilities of the Project Manager (PM), of course, is his or her management of the project delivery team. This is where the real work happens, where the rubber meets the road and how the project moves productively forward. It is a lot of responsibility and takes some obvious skills and planning to do it right… beginning with getting the resources planned, through project kickoff, and on to the actual performance on the project.  Let’s discuss…

Business team of success pop art retro style. The joint work. Business success. The schedule of growth. the business staff. Firm
Good oversight leads to a team that works together and is successful.

Resource Assignments

Let’s assume the team is assembled by leadership within your organization. I’ve been in organizations where one person managed the PM Office and assigned PMs to projects based on availability, geographic location, and expertise, and another person managed the Business Analysts (BA) and made assignments to projects based on those same considerations.

The technical staff is usually managed by a Development Manager or CIO (or both) and the technical resource assignments are made based on availability and expertise and they are often not full project timeline assignments like the PM and the BA positions. Those technical resources are assigned as needed and as determined by the project schedule and resource forecast maintained by the Project Manager.

Kickoff

Prior to the Kickoff of the project, the PM distributes all relevant project and contract information to all assigned delivery team members. This would usually include, at a minimum:

  • Statement of Work (SOW)
  • Original resource hours forecast/budget as finalized by Sales
  • Initial project schedule as created by Sales for the customer
  • Contact information for project team members on both sides
  • Any relevant travel and expense requirements as mandated by the customer

In addition, the Project Manager and the Business Analyst are preparing heavily for the Kickoff Meeting with the customer and planning for the move into Exploration. Frequent, ad-hoc communication is happening at this point to coordinate efforts and ensure that both are on the same page.

Onboarding

Once Kickoff is over, technical resources will begin being assigned (as needed) to the project and the effort of managing the delivery team resources and forecasting for their usage becomes a more important task for the Project Manager.

As new resources are engaged on the delivery team side, four things must always happen…

  • Provide the relevant project/contract docs for review
  • Provide recent status reports and the project schedule for review
  • Provide the resource forecast for review
  • Hold a formal delivery team meeting to go over current status, key project info, and answer questions

Ongoing oversight of project tasks

Once the project is fully staffed and is moving from Exploration to Design and beyond, then the effort of overseeing the work of the delivery team members should be fairly straightforward. Maintaining proper communication and the structure that should already be set in place will help ensure that each team member is up-to-speed at any given time on project status and what is expected of them at that moment and for the upcoming weeks. Just to review, this proper communication/structure should be in the form of:

  • Weekly delivery team meetings
  • Ad-hoc delivery team communication
  • Weekly formal status meetings with the customer
  • Weekly delivery of and review of the revised project schedule
  • Weekly delivery of and review of the project resource/budget expenses and forecast

Summary & Call for Comments

If all of these items are well maintained and delivered to team members in a timely fashion, then everyone will be on the same page. The Project Manager must be well organized because usually the PM is dealing with delivery team members who have other projects to work on that are in various stages of implementation.

Your delivery team members must always be made aware that this project is critical and that you have a solid structure in place or you’ll lose them to other activities and you’ll have more difficulty re-directing their efforts back to your project tasks. It’s much easier to lose resources to their other critical activities on other projects than it is to reign them back in … so stay organized and fight to not lose their focus in the first place.

Readers – how does this match up with your experience and expectations? Please share and discuss any additional information you care to add. Thanks!

Man Hand writing Scope with black marker on visual screen. Isolated on white. Business technology internet concept. Stock Photo

The Need to Negotiate with the Project Client (Part 2 of 2)

Are you a skilled negotiator? Does negotiating make your hair stand up on end or does it drive something in you?

In Part 1 of this series, I discussed negotiations for Budget and Timeline impacts on your project. I identified that issues requiring negotiations on projects usually fall into one of three main categories: Budget, Timeline, or Scope.

For this article, let’s look closer at Scope negotiations and how best to handle them with your customer.

Scope Negotiations

We all know that scope issues can abound on any given project – especially if some loose ends weren’t properly tied up during the sales process. I think the Project Manager should be involved in at least a portion of the sales process. When I worked at Rockwell Collins (RC) in the late 90’s and early 2000’s, all the projects were internal for in-house business units – I WAS the sales process. As was the case with all the PMs at RC, I handled:

  • Meeting with the customer
  • Documenting the business need
  • Pricing the engagement
  • Finalizing with the customer
  • Presenting the proposed solution to a technology council for approval

Sorry … enough plugging for the PM role in sales … for now.

Man Hand writing Scope with black marker on visual screen. Isolated on white. Business technology internet concept. Stock Photo

Back to reality. Scope issues are a fact of life, they will always happen. When the customer says, “but I thought that was included,” you have to look at it from their side as well as your own. Do some investigation. Maybe Sales told them it was included? Maybe the line was a little gray? Or maybe you can see some bigger work that is coming down the line on the project in terms of scope and now is the time to negotiate.

At any rate, it’s about the give and takes. For most scope issues you’ll:

  • Draw up a change order
  • Identify the budget and timeline hits
  • Present the customer with the cost factor for adding the extra scope

If they balk, there may be some room for negotiation – for example, price the implementation of the new functionality but throw the training in for free. Of course, you may need senior management approval for this – another form of negotiation, possibly. Explain the need for customer satisfaction, retention, and referral, or possibly your vision for some bigger add-on work that you can see in the offing.

Another issue that can lead to major scope concerns and the need to negotiate is the lack of previously defined customer business processes or poorly defined customer requirements. As the Exploration Phase gets underway, this issue really can come to light – if it hasn’t already. As the PM, this is when I look for the opportunity to negotiate with the customer in terms of creating additional revenue for the delivery organization in the form of a Change Order.

It’s obvious at this point of the project that (for example) a two-week Exploration Phase is not going to cover everything that is needed. You’ll need to explain to the customer that:

  • More time and effort dedicated to Exploration is needed.  These additional hours and $$ should be in the form of a Change Order to properly record requirements and create a meaningful:
    • Business Requirements Document (BRD)
    • Functional Design Document (FDD)
    • Technical Design Document (TDD),
  • That the increased effort added up front helping the customer define their business processes and requirements will result in a more solid solution being deployed to the customer at the end of the project.

It shouldn’t be too hard of a ‘sell’.

Summary / Call for Input

I’m not sure any of us really thought we’d be negotiators when we entered into the PM field. But it seems to come up regularly on projects.  We’ve examined Scope Negotiations in detail here.

Readers – what are your thoughts on negotiations? Are you good at it? Have you found yourself in the negotiating role with your project clients from time to time?

Business cartoon about negotiation. The company needs someone adorable, cuddly and cute for the negotiation: the panda.

The Need to Negotiate with the Project Client (Part 1 of 2)

Negotiation is a four letter word to some people, and a passionate love for others.  Is negotiation part of the Project Manager’s role?  It certainly is.  In fact, without realizing it, the act of negotiating things on a project probably infiltrates just about every role occupied on a project … but it’s certainly most prevalent in the Project Manager role.

Reasons for Negotiation

Let’s take a look at reasons the need to negotiate may arise on an IT project.

  • Functionality needed earlier than expected
  • Out of scope work that needs to be included in current timeline
  • Customer request for a different resource or skill set
  • Data management issues and who handles them
  • Customer training
  • Budget issue vs. Timeline issue

The list can go on and on … these are just a few of the ones that I’ve personally run into on my projects.

Generally, the issues fall into one of these three categories:

  1. Timeline,
  2. Budget or,
  3. Scope (Covered in Part 2)

Unless the PM is being micro-managed from above by executive management or the PMO Director, the role of negotiator – at least from a customer-facing perspective, falls to the Project Manager.

This is the first of a two-part series on the need for negotiations with the project client from time to time. In this first part, we look closer at Timeline Negotiations and Budget Negotiations and how best to handle each type with your customer. Part two covers how to handle Scope Negotiations.

1. Timeline Negotiations

Negotiations on timeline issues can take on many forms.  For me, the most common timing issue has been the request for functionality to appear earlier than previously expected.  While this can sometimes be a major headache depending on the project, I try to take the phased approach if it is appropriate.  By this I mean, negotiating with the customer on implementing functionality in phases.  To do this, I follow these steps:

  1. Review the request for functionality
  2. Discuss with the delivery team experts
  3. Re-work an alternate project plan to move the requested functionality to early in the timeline
  4. Document a narrative for the customer outlining what needs to be pushed to later in the project to make it happen
  5. Conduct a formal meeting with both teams to present the proposal

Generally, my presented proposal consists of:

  1. Restructured priorities
  2. Moving the needed functionality to an earlier point in the timeline
  3. Implementing the functionality
  4. Creating later phases for the remaining functionality

It may also impact the budget, but if it gets the customer the functionality they desperately need when they desperately need it, then they’re probably very willing to accept the budget change it requires (this has always been my experience).

2. Budget Negotiations

The most common budget negotiations I’ve run into have been either:

  • Higher-priced resources needed or requested on the project

If it is warranted by the project due to some undocumented needs by the customer, then I’ve often been able to ‘sell’ the customer on the higher-priced resource.  If it’s the other way around – meaning the delivery organization wrongly assessed the resource needs, then the push needs to be to get senior management to agree to give your project the more skilled resource and bill the customer the same lower rate.  As the PM, you still need to explain that to the customer – never miss an opportunity to gain additional customer satisfaction by letting them know you’re always fighting for them.

  • The need for some unexpected customer training

In the case of the customer training…  And it doesn’t have to be customer training – you can insert any one of a number of similar items here.  But for me, it’s usually been customer training.  The customer hasn’t realized the need for some training (usually due to a communication issue during the sales process), but it’s still needed and it isn’t cheap.  Work with the customer and determine options.  What’s worked for me, has been to coordinate with both the customer and the training department to price a training session on site for the customer rather than have the customer send everyone to the training department.  This results in significant customer cost savings while bringing in new streams of revenue to departments in your own organization.

Part 1 Summary & Discussion Questions

I’ve mostly talked about the need for external customer negotiations.   However, the need to negotiate also comes up regularly in your own organizations as you work to obtain resources, equipment, budget, and etc.  The good Project Manager draws on experience from a history of customer dealings to enable them to effectively negotiate for things on their project with everyone involved in it.

How have you dealt with Timeline and Budget negotiations? What has worked, or not worked?

Continue to Part 2.

Communications Plan, Checklist format

How Important is a Project Communication Plan?

How important is communication to project success? In my opinion – it may be #1 on the list and it is certainly a major responsibility of every project manager who has ever led a project.

Whether or not your project or your customer requires a delivered Communications Plan, you should still have one … especially if you are dealing with an external customer rather than an internal organization.

Every time I’ve delivered a Communications Plan to the customer, they have been pleasantly surprised and pleased that the communications on the project have been put in writing at the earliest possible point and in sufficient detail.

Communications Plan, Checklist format
A basic Communications Plan checklist.

If you are interested, you are welcome to download and use my example Communications_Management_Plan.doc file to get started. In addition, FastTrack Schedule provides several (all are free) working templates for different types of project plans (i.e. project management schedules), which may be useful project starting points.

Communications Plan.

The high-level items that should be covered in the Communications Plan are:

  • Introduction
  • Methods for Gathering and Storing Information
  • Distribution Structure
  • Formal Project Communication Matrix
  • Sign-off Page

I’ll go into further detail on what each of these five sections should cover on a typical project:

1. Introduction

This is merely a high-level description of what the document covers. It should also identify the delivering team or organization and the customer or internal organization that the project is being performed for (and likely paid by).

2. Methods for Gathering and Storing Information

This section is for identifying both the formal and informal communication and how this information will be stored and shared across team members on both sides. Formal communication includes weekly status meetings and the dissemination of information through weekly status reports, revised project schedules and issues and risks lists. Informal project communications include email and phone ad-hoc transactions required to update, clarify and disseminate relevant project status information.

3. Distribution Structure

The distribution structure section of the Communications Plan identifies how the formal communication on the project will happen and who will be involved. The distribution structure contains sub-sections for each type of formal communication and outlines specific information for each type…Project Status Meetings, Project Status Reporting, Project Schedule, and any shared distribution or posting site such as a sharepoint site or wiki.

For each of these formal communication items, the plan identifies how each is delivered, who receives them and how often they are delivered and reviewed.

4. Formal Project Communication Matrix

The formal project communication matrix is basically a visual representation of the distribution structure for any formal project communications. This can be through the use of a graphic or table that provides the delivery team and the customer with a quick reference of the communications that happen on the project.

At a minimum, the matrix should include:

  • The type of communication
  • It’s originator
  • Who receives the communication or attends the meeting
  • The frequency that the communication or meeting occurs
  • And the source of the communication or meeting

5. Sign-off Page

Whether the Communications Plan is a formal deliverable on your project is up to you – or possibly your customer. Either way, I strongly believe that a formal sign-off is important as it sets the stage for all communications and information expectations for both project teams going forward. Therefore, the final page of the Communications Plan should be a sign-off page for the Project Manager and the customer-side project sponsor and this document should be retained, managed and modified as needed (with sign-off on any changes) as the project progresses and any necessary communication methods are added or changed.

Summary / Call for Input

For me, communication is Job One for the project manager on the project. They do lots of important work, but efficient and effective communication should begin and end with the PM.

What about our readers? Do you consider communication plans that important? Do you produce a Communication Plan on some or all projects?

A businessman takes his sick piggy bank to the doctor

Project Warning Signs – They are Real

If you get sick … where do you go? The doctor, right? I realize some people are afraid of doctors and avoid them at all costs … but the answer is you go to the doctor. And whether you go or not, probably depends on your symptoms (warning signs).

Don’t ignore those medical issues. A good friend and colleague recently had a medical scare – sort of a mini-stroke / warning stroke that usually doesn’t cause any injury as long as you recognize it and get treatment fast. He did – thanks to his very observant and fast acting wife – and now his likelihood of an actual follow-up stroke is greatly reduced because he got treatment quickly.

Why am I saying this? Because doctors are important! No, that’s not why … but they are. So don’t be stupid!

A businessman takes his sick piggy bank to the doctor
Even projects get sick and when they do, it’s your piggy bank that hurts

The project management relevance… the point I’m trying to make is this, we get warning signs all the time in our lives – personally and professionally. It’s what we do with them that can determine how badly they affect us and what happens next. Two personal life examples: Your brakes squeak and if you don’t replace them, you’ll also be replacing your rotors and it will cost four times as much; The meat in your fridge smells bad … don’t use it. If you do, you’ll be … well … you’ll be real sorry, trust me.

The projects that we manage have warning signs as well. A good way to identify warning signs is to pay attention to deviations to your project plan, using project management software (such as FastTrack Schedule) can help with this.  Project financials that start to go south … first 5% over budget, then 12%, then 27% after a couple more months … are very real. If you ignore the early warning signs, you may find yourself too far down the road on your project to take any meaningful corrective action. How about a vendor that you’re using to deliver equipment over several months for major project? The first delivery is two days late. The next one is five days late. The third one may be on time, but the fourth one is three weeks late and you’re expecting several more deliveries from this vendor. If you don’t take action – and quickly – you’re going to find yourself with major delays or possibly even a situation where you can no longer get any deliveries from this vendor due to whatever issues they may be going through on their side of the project.

What I’m saying here is this … these are big warning signs and they are only two examples out of potentially hundreds I could come up with. Yes, so many things can go wrong, but we still need to be aware, plan, and be ready to act or react … and sooner rather than later.

How do we do this? Well, it’s basically risks that are lingering out there that are actually coming to fruition and threatening the well-being of our projects, correct? So the basis of this is good risk planning. To often, we procrastinate, minimize, or even outright avoid risk planning, which is a bad choice. While we can’t plan for all risks, we can plan for major ones based on our experiences, our teams joint experiences, and our project customer’s experiences, and business environment. All of these play a major part in our risk planning and management process. We should, at a minimum…

  • Brainstorm with the team on major potential risk
  • Bullet point some response steps to each potential risk
  • Identify an estimated likelihood that the risk will occur
  • Assess the potential damage the risk could cause
  • Swear to revisit this risk list at least monthly (preferably weekly) on the project

Being proactive is of huge benefit to our health and to our projects. And at the very least we often get some sort of warning sign that tells us something is different … something is amiss. Only a fool overlooks those warning signs as nothing to be alarmed about. Check it out … the worst thing that could happen is actually the best thing … you could be wrong and you just go back to the status quo.

Summary / Call for Input

Risk management or risk planning are dirty words we hate to hear. It takes time and money to tackle possible risks. But really, it can be done in 30 minutes with the right focus. 30 minutes of risk discussion may help you and your team avoid a $50,000 oops later down the road on the project.

How about our readers? How many of you are good about risk planning? How many of you have missed a warning sign on your project, lived to tell about it, and care to share it with the rest of us? Let’s share our risk and issue experiences and discuss.

Businessman hand pouring money down the drain in the form of gold and silver coins

When Funding the Project Becomes an Issue

Ideally your project moves out of Sales and into the actual engagement stage with expectations properly set and a solid timeline and budget in place. Ideally… But we all know that there can be bumps in the road and incorrectly documented or relayed expectations, requirements, etc.

Customer requirements and expectations may not be on par with the actual derived budget and that potentially major issue may rear it’s ugly head early on or it could even come up very late in the project causing major issues, work stoppages or project cancellation. It’s our job to avoid those events at all costs, but sometimes they do happen – and we have to react.

Businessman hand pouring money down the drain in the form of gold and silver coins
Funding issues equal loss of money

Delivery Team Funding Issues

There are several issues that can cause delivery team funding to hit the wall. Here are some examples:

  • Development bug that takes longer than anticipated to complete
  • Need to put more resources on a project to complete critical tasks
  • Need to put higher priced resources on a project to work through issues
  • Data handling and/or loading taking longer than planned
  • Underestimated or misunderstood customer requirements

The key difference between delivery team funding issues and customer team funding issues is that they really have to just be worked through. What delivery organization – in their right mind – is going to just throw up their hands in the middle of an implementation and say, “we’re done…we’re not going to throw any more money at it?” I realize it’s happened…I’ve even experienced it myself, but it’s much rarer than the customer giving up and not deciding to spend any more on a project.

In reality, the delivery organization is more likely to eat the budget overrun in hopes of completing a successful implementation and retaining an important customer. Ultimately the amount of the budget overrun will play a role in the decision, but if the budget is being tracked along the way as it should be, then the delivery team has likely been strategizing for some time to lessen the overall financial drain while still working to keep the project going and the customer at least somewhat satisfied.

Customer Team Funding Issues

The more critical issue is when the funding problem is on the customer side. This can present itself in two forms:

  • Project budget overruns have taken their toll on the customer funding and the delivery organization is not willing to eat more overage – meaning it’s now the customer’s problem
  • Internal issues at the customer organization are affecting their ability to fund remaining portions of the project as originally planned

When the issue is customer funding, and if it’s big enough, the project is likely to be cancelled. However, if it’s only a few thousand dollars, then it may survive. Negotiations will start between the delivery organization and the customer organization and a deal may be worked out to spread the financial responsibility across both or the delivery organization may take the full load in order to keep the project going. But if the budget issue is large enough, then there is likely no other course the customer will take than to cancel the project.

Project Restart?

The outside possibility may remain that the customer will restart the project when funding increases or returns. If that is an option – and it very well may be (at least the delivery organization is likely to retain that hope for quite awhile), then the deliver organization is faced with a new dilemma…how to keep the project team relatively intact if the project may resume soon.

If there is a possibility that the project will resume, then discussions must happen quickly with the customer to determine what time frame within which that might occur. If a restart is a possibility, then it may be possible to make strategic assignments to other projects for the key project personnel can be made in order to keep them somewhat available if the project resumes.

Summary

Budget issues may be the single biggest problem that can occur on a project. If you’re out of money, you’re out of money. Throwing more resources at it won’t help – it will only make this particular problem even bigger. And either way, the project is still dead, and one or both organizations are embarrassed, experienced major failure and may have personnel issues to now deal with.

The best that can happen is to learn key lessons from whatever issues caused the budget issues. If it’s a poorly run project, then retraining or termination of certain personnel may be necessary. If it’s poor planning or a sales issue, then measures need to be taken to not repeat the same issues again. If it’s a delivery organization budget issue, it’s critical that the causes are reviewed, documented and understood so that history does not repeat itself.