professional services

Chasing the Number

Forecasting is easy, but doing it well is hard. I am talking about financial forecasting that is required of project managers engaged in the business of delivering professional services.

Before we get into how to forecast, let’s look at why we forecast. It is an essential part of managing the flow of business activities aimed at achieving a goal that has been set. The idea is to look into the near term future and make an informed guess as to the billable milestones that will be achieved by a certain date. If the forecast deviates too far from the goal, you and management will have the opportunity to take action to put things back on track.

It also is used to set expectations for income, which can be very important to stock performance (I have a special rant related to this but won’t go into it in this post). Since we are setting expectations, we better make sure we achieve those expectations or else we will find ourselves in an unpleasant situation.

Now that we know why we make forecasts, let’s see how it is done.

As I said at the beginning, forecasting is easy. You assign a number to a date and you have a forecast — easy. But how do you know it is the right number and the right date. That is the hard part. It is hard because we are making guesses and guesses are easily influenced by our internal desire to make the goal setters happy by giving them the number requested. But if we don’t know if the number given is going to happen, everyone could be in a world of hurt when the goal date arrives. This is a case of trading near term happiness for long-term sorrow later.

The key to giving accurate forecasts is to have a set of rules to follow that help keep emotions out of the equation. This will also make forecasting much less stressful. Here is what I do that has worked fairly well for me so far.

All milestones start out with a forecast that puts them beyond the current forecasting period, such as the next quarter or even next year.
Once a milestone has been planned and scheduled you can then assign a completion date that you will have some confidence in actually happening.
Modify your forecast every time you complete a status call or receive new information relating to the schedule.

Following these three rules will make forecasting easier, more accurate and less stressful. Of course it may not make life pleasant if the number you are forecasting does not meet the desired goals. But actually, that is a good thing since the whole point of forecasting is to allow management a chance to take action to achieve the goal before it is too late. By following the rules above you are making fact based guesses that are supportable and defensible because they are based on solid information. The same is true for changes made in the forecast since as circumstances change so does the likelihood of achieving the goal.

Using fact based forecasting methods is the only way to do it. You have to not let the pressure from the person who sets the goals drive you into giving a number that cannot be supported by facts. Following the rules will keep you on track. As you develop a reputation for having accurate forecasts, your value to the company will rise and you will have pride in how you deliver.

Work at Risk Projects

In the professional services world there is a euphemism called “working at risk” which means that you do not have a signed SOW or contract or even a PO. You are running a project without an agreement on scope or goals, no defined budget and no authority to expend resources or bill for them.

Before I get into talking about how this comes about and how to deal with it, let’s understand the importance of a signed document defining the project. In professional services (“PS”), we are usually talking about a Statement of Work (“SOW”). This document does several things:

Defines the scope of the project.
Defines the roles and responsibilities of both the receiver and the provider of services.
Establishes a budget for the work and terms and conditions to control that budget.
Defines the milestones at which payment is to be received and what criteria for success is needed to meet those milestones.

A document with all these things, agreed to by both parties through legally binding signatures, provide the PMO and the assigned PM the authority to perform work. It also provides guidance on the scope of the work to be performed as well as giving all parties a way of determining when a change order is required. A well written SOW is the first step in having a successful project which will result in an outcome that will provide satisfaction for all stakeholders.

With that said, why would anybody deliver services without a signed SOW? I have been thrown into this situation a number of times over the years. In my experience, this will work without major problems about half the time if certain characteristics are present. Some of them are:

It is a good customer that has an emergency situation and there is not time to complete the paperwork before starting the services. The paperwork comes shortly after work begins. I find this situation fairly low risk.
The opportunity for current and future work and sales are large and upper management from both sides have come to verbal agreements through direct contact with each other. The risk in this situation is a bit higher but you will have authorities from both sides that you can engage to help keep thing on track.

Work at risks projects that do not have at least one of these characteristics have a high degree of risk and should be avoided at all costs. You as the PM should make it known from the very beginning that proceeding is very risky and not recommended. Make sure these opinions are in writing or some other audit trail such as email. This is not only a CYA strategy, but is also your duty as a PM to let stakeholders know when you see problems with a project.

Ok, so despite all your efforts, you are assigned to a project that is a work at risk situation. What do you do about it?

The very first thing you need to do is work with the customer to define the work to be done. This will give you a scope that you can manage against and allow plans to be made. If the customer does not want to go through a planning stage or provide metrics to gauge success then you need to shut the project down until agreement is reached. Continuing to move ahead without a plan will not bring satisfaction to anyone and can do great damage to your own organization’s reputation, costing you future business.

The fact that a budget has never been established requires that you keep track of hours worked and expenses incurred and report them weekly. Make sure you negotiate a time and materials billing approach since you have no definition of billing milestones.

You will have a larger task of documenting all decisions in greater detail. Make sure your meeting minutes are more detailed and they are published to the whole team. Obtain agreement often on progress made and publish that as well. There is no such thing as over communication in a work at risk project.

Hopefully, this post will help you avoid work at risk projects or at the very least give you some strategies for dealing with them. Let me know your thoughts on this post or any of my other posts.

Gantt Charts – Double Edged Sword

Anyone who has done PM work is familiar with a Gantt chart. It is a wonderful combination of text and graphics that lets us see dependencies, durations and start and stop dates. It is a very useful tool for planning and tracking your project – but it has a dark side as well.

First conceived in 1896 by Karol Adamiecki but first popularized by Henry Gantt around 1915, the chart was a labor intensive means of visualizing the flow of a project and the relationships between tasks and milestones. Every time a change was made in any aspect of the schedule, the whole chart would need to be manually re-drawn. Not until the advent of software to take care of updating and changing the chart did the Gantt chart become widely used.

The software I have used often to plan the execution of projects over the years is MS Project. There are other software tools just as capable but my experience has been limited to MS Project. I don’t believe this will invalidate any of the ideas I will be expressing in this post since it addresses the perceptions surrounding Gantt charts and the strategies of their use.

Because of the wide use of this type of software, the past three decades have seen Gantt charts become a common and often an expected document in status reports to management and other stakeholders. In my mind, the Gantt chart is not meant to be a status reporting tool, but rather it is a planning and tracking tool to be used by the PM and his/her team to manage their activities. This misuse as a reporting tool has lead to a couple of perceptions that I find problematic.

The first perception that goes against the grain of those of us who understand the technical details of project management is the idea that the Gantt chart is “The Project Plan“! This is far from the truth, since the Gantt chart represents only one aspect of a total project plan, the schedule.

A project plan is made up of many parts that cover not just the schedule but such things as the communications plan, risk plan, resource plan, scope definition and all the other items that make up a total project plan. Calling the Gantt chart a project plan puts too much focus on the schedule and can lead to misunderstandings and incorrect perceptions of the project.

The second perception that causes problems, is the fact that people perceive the schedule presented in the Gantt chart as immutable and set in stone. Maybe this would be true if we PMs had access to a crystal ball that could tell us all the things that we will encounter in the execution of a project before we started. But since such a thing does not exist, the expectation that a Gantt chart does not change is unrealistic.

The Gantt chart is, as I said earlier, a tool for planning. As such, it is used to project what our current knowledge says should be the schedule. With new knowledge gained – as we uncover things we did not know earlier – we are able to use the tool to see the effects of this new knowledge. Since the Gantt chart depicts the work efforts and dependencies, it allows us to see the impact of changes and thus allows us to adjust our plans to react appropriately to the changes.

Due to the above perceptions, I have a few strategies I use when dealing with Gantt charts.

First, I make an effort to refer to it as a schedule, not a project plan.
Second, I try to avoid using the Gantt chart as a part of a status report.
Third, in those situations where I must provide a Gantt chart style of reporting, I will create a high level chart that excludes specific dates and shows durations over periods of weeks or months.

I would be most interested in hearing from you on how you view the use of Gantt charts. I am sure there are other strategies and views on this subject that I could learn from.

Just the Facts

In my previous post I talked about how to deal with mistakes that I as a PM make. A sometimes more difficult situation, is dealing with mistakes others on your team (coworkers or customers) make. The general approach is the same as for your own mistakes, but must be handled with more delicacy.

Humans are complicated creatures and they each develop their own particular view of themselves and the world around them. When someone makes a mistake, a broad range of reactions can be observed. Some cannot admit to making a mistake and will react with denial and even push the blame to someone or something else. Others are mortified that they made a mistake and will punish themselves to the point of becoming unproductive or withdrawn. There are many other reactions that are exhibited besides these two, but I will not go into them at this point. Just suffice to say that most of them are bad in some way.

Talking about others mistakes in a public forum will amplify these reactions and usually result in defensiveness, arguments, name calling and sometimes hanging up on the call or storming from the room. All of these scenarios are bad for the team, bad for customer relations and bad for the project. However, anything in a project that affects scope, schedule or budget needs to be documented, analyzed and reported. How to do this with minimal impact to the inter-relations of the team mates and stakeholders is the meat of this post.

Let’s say the scenario is a data center move is scheduled for a weekend and all systems needed to be back up and fully tested by Monday 8 AM. While bringing the systems back online, problems were encountered where critical applications were unable to connect to their data sources. This results in the whole team working day and night, Saturday and Sunday and on into Monday. The problem is not resolved until 10 AM on Monday. It turned out that two mistakes were made in the network configuration having to do with a route statement and a firewall rule. A single person was responsible for the configuration of both items.

The crucial things to remember when reporting or discussing the mistake is to stick the facts and keep personalities out of it. In this case I would report in my status that “An incorrect configuration in the firewall rule was detected and corrected and a route statement adjusted to the correct route.” Note that no one was named as being at fault. This is as it should be. All humans make mistakes and there could be extenuating circumstances such as the person responsible could have been working for 24 hours straight when the mistakes were made.

The followup postmortem would concentrate on the nature of the failure and that it was human mistake and not that Joe fat fingered the commands. We would then move on to a quality control plan to provide some kind of check and balance for future actions.

The important points to keep in mind are:

Stick to the facts
Keep personalities out of the discussion
Make no judgements

I would be interested in any comments or feedback you might have on this post. Please take advantage of the comments section below. Your email will not be used for anything beyond helping me combat spam.

Dealing With Mistakes

Recently, I screwed up. On a simple install I set an expectation with a high-profile customer that was completely out of scope. Offline, the engineer and SE let me know the extent of my blunder. It was going to open a black hole of services that we would not get paid for. Crap! What do I do now?

My mind races going through the various scenarios that could ensue.

I could just ignore it and hopes it goes away. But, that is not likely, since the customer now has an expectation that he will be anticipating.

I could throw my hands in the air and quit this job. But that won’t work either. I need the income and I like what I do.

I could pass it up to a higher level to be dealt with. Again, that is not a good solution since I am sure management would not be pleased and besides, I made this problem and I should be the one to fix it.

But how?

We, as PMs, we are charged with leading the project and making sure all of the stakeholders needs are addressed and if possible, satisfied. People expect us to know what we are doing and not to make mistakes. But alas, we are only human and we make mistakes. The more experienced you are the bigger your mistakes are when they happen – and they will happen. I have found that there is only one way to deal with this.

I got on the phone with the customer and explained that I had not understood the simple addition of task that I had said we would do had a lot more baggage attached to it than I had been aware of. There were design and troubleshooting aspects associated with the task that would take us way out of scope and really should be addressed as a separate project. The customer was not happy to hear this but after some discussion he accepted the situation and my apology. The next day on the status call, I explained the situation to the whole team and we are now moving ahead on the simple install within scope.

The fallout from all of this is not as bad as I had thought it might be. In fact, the customer is now seeking more professional services from us to help implement the added scope. Prior to this, he had been looking at doing it on his own.

This experience reminded me of things I have learned over a number of years dealing with customers.

Don’t let issues fester. Deal with them as soon as possible.
Honesty is always the best policy.
Admit to and take ownership when you make a mistake.
Many times a problem can turn into an opportunity.

Let me know what you have done to deal with mistakes. There are always more than one way to deal with them.

What is IT Professional Services

In the world of Information Technology (“IT”), Professional Services (“PS”) generally refers to services that are delivered by a person(s) who is a specialist in a technical arena. This is a broad category, as well it should be, given the great variety of technologies in use and how they are applied in any IT department. It is because of this great variety that there is a need for PS.
Continue reading What is IT Professional Services

Share this:

Share this:

Share this:

Share this:

Share this:

Share this:

Share this: