Although this is a bold statement that really does not account for any outliers or edge cases, it can be surmised that performance on the job should have a direct correlation to continued employment at said job.  The problem then is that for those companies that do not do successful performance management (a debate unto itself), tend to feel the pain of that during such bad economic times.

During the tougher times, companies tend to rely on a more leaner model where people are either laid off or offered early retirement.  So, what happens if neither of those options are appealing?  This is when I believe that companies start to place a stronger focus on performance management and “performance managing people out”.  When times were good, it was okay to let the weaker performers stick around as they really weren’t hurting the company that much.  When times get bad, it becomes apparent that the weak performers are actually impacting the bottom line.  They are not contributing (contributions can be measured differently based on the industry but every job does have an output that impacts the bottom line in some way) to the bottom line and thus become a way for companies to cut costs during the leaner times.

There is an obvious answer to this problem, but implementation is another issue unto itself.  Without going into the overall importance of performance management (broadly speaking, anything dealing with ratings, reviews, feedback, etc.), it is imperative that companies that practice this methodology during tough economic times take this as a learning experience to consistently do performance management, even when the economy is booming.

There are a few reasons for this, but I will highlight what I think are the 3 most important ones.
1) You owe it to your employees, both the over-achievers and under-performers to provide them timely, meaningful feedback.  Even if that feedback is negative, bad performance is bad performance regardless of what the stock market is doing.  If somebody is not performing, they need to get that feedback and then improve their performance to maintain their current state of employment.  This also goes for the over-achievers.  As a society, we often times forget that even those who are quite successful in their positions need to get feedback.  Nobody is perfect at their jobs and performance management is a perfect way to help the over-achievers reach an even higher level of performance.

2) It makes sense to be consistent.  I would certainly never defend a person who is not doing the job that they are expected to do, but I would defend them if they did that job for a certain period of time and did not receive any feedback about performance, until there was a need to reduce the workforce.  Performance management needs to be done consistently.  It is hardly the ethical thing to let somebody under perform for months, or even years, and not do anything about it, until it becomes necessary to “trim the fat”.  “Trimming the fat” should be done during the good times and the bad times.  It is an unfortunate truth, but people are replaceable.  It is expensive and time-consuming to do it sometimes, but it needs to be done when we are thriving and when we are not.

3) This may seem repetitive, but performance management is a crucial part of the way we do business and the way businesses succeed.  If you find yourself using performance management to get through the tough economic times, try to keep the practice of performance management alive and strong even after the economy recovers.  Just because we have done things one way for so long, does not mean we cannot right the ship.

I think the best way to start to explain RACI is to actually walk you through an example of how it could be used when planning a tailgating party.  So, here is some terminology that you will need as we walk through this just so we are all on the same page.

R = Responsible: the person who performs the action/task

A = Accountable: the person who is held accountable that the action/task is completed

C= Consulted: the person who is consulted before performing the action/task

I = Informed: the person who is informed after performing the action/task

So, the tailgating example is quite simplified and I could easily foresee a RACI Matrix being made up of many more tasks and many more people.  In this case, let’s just assume there really are only 3 roles – host, co-host, and attendee.  Since we are going to aim to have more than one person at our tailgate, we will go with multiple attendees.

I have broken down the tailgating in to areas – which are essentially larger buckets where all of the tasks can be assigned to.

Let’s breakdown this RACI Matrix.

The first thing you should notice is that no person has more than one role per task.  For instance, you cannot logically be both responsible for completing a task and the same person who is consulted.  It is assumed, for instance, that a person who is accountable for a task is also responsible if there is no other person in the row with an “R”.

The other thing you will notice is that not every task has an “R”, “A”, “C”, and “I”.  The reason for this is that the RACI matrix forces you to think about who really needs to be involved in each task.  In other words, it helps to visually display where micromanaging might be occurring.  For instance, let’s take the task of bringing the music to the tailgate party.  The matrix currently has attendee A as responsible for this and they are to consult the co-host about it and then ultimately inform the host after the task is complete.  This is a perfect opportunity for the host to really think if they need to be informed of the completion of this task or if they can instead delegate not only the consulting but being informed upon completion to the co-host.  Obviously there are plenty of times where there will be unique people to fulfill each of the four roles, but this matrix can help in starting those discussions to ensure that every person is in the right role and people are not duplicating effort.  Or, could we even remove the consulting for the co-host and just let the responsible party inform the host when the music has been selected.  Often times, people are consulted just to make sure everybody feels good about a decision being made, but it is sometimes not necessary.

Notice that for the task of football, there are 2 parties responsible for it.  This could cause a couple of issues.  The first of which being, does each person have the same expectation of what they are responsible?  Does one person know they need to bring the football and the other person know they need to bring the pump?  Having multiple “R’s” for one task can lead to ambiguity.  In these cases, you should always try to see if the task can be broken down further.  Also, when there is more than one “R” there could be overlap if the two parties do not communicate.  So, on game day, both attendee A and attendee B could show up with the pump and no football.

Another area of focus would be having too many “A’s” for one person.  This type of situation can lead to bottlenecks where one person is responsible for many tasks.  In such cases, try to think of ways where the tasks can be shared across resources.  Often times, this is an opportunity to have a more junior resource be held accountable for an manageable task.

So, now we have looked at a RACI Matrix as it related to planning a tailgate party (note: the chart was purposefully not done optimally to demonstrate the various aspects of a RACI matrix), but let’s try to bring in the overall benefits of using such a methodology on a project.

The first thing that RACI helps manage is the idea of having too many cooks in the kitchen.  If we are able to break projects down in to manageable tasks and then assign people to them in the form of who is accountable, responsible, consulted, and informed, you will be able to see where there may be too many people with their hands in the pot.  In these cases everybody thinks they are responsible and or accountable for task and this only leads to confusion and duplication of efforts.

Another area that RACI helps manage the concept of is that some people think they need to be consulted about tasks, when in fact, they only need to be informed after the task has been completed.  I like to think of this as trying to lessen the amount of micro-managing.  You have to have trust in the people who are responsible and accountable for tasks that they will complete them successfully and then inform you upon their completion.  For instance, I frequently work on functional designs and only upon completion do I inform my project manager that I am done.  There is no reason for me to consult him when I am in the process of doing the task as there is trust and a level of accountability there that I will complete the task.

Finally, I think RACI can be leveraged when a new resource starts on a project.  By creating a RACI matrix you can easily lay out the tasks that various people are working on and their respctive roles as they relate to the task.  I am currently using this appraoch with a new resource on one of my projects and although we certainly have not been using it for enough time to determine its’ effectiveness, I can say that it was received well and certainly laid out clear expectations for the person’s role.

Scope creep at the buffet

An American classic … the all you can eat buffet.  Give me $16.99 and I will give you food.  Take as much as you want while you are here.  Stay awhile; make yourself comfortable.  Take advantage of the fine offerings.  Indulge in items you did not know even existed.  Bring the whole family.

Scope creep … a consulting demon.

Now, you may ask what do the all you can eat buffet and scope creep have in common.  Quite simply, the customer/client thinks they can have anything they want since they gave you money.  In the case of the buffet you can select whatever you want and take as much of it as you want.  In the case of a software development project, you cannot do this, but often times the client thinks they can.

According to Wikipedia it is quite simply “uncontrolled changes in a project’s scope.”  In my terms, it is the inability for a project to stay on its’ predetermined time line with its’ agreed upon features due to; 1) incomplete or inaccurate definition of the project requirements, 2) poor communication between parties, 3) weak project management, and/or 4) lack of solid change control process.

Scope creep seems to be an inevitable and unavoidable fact of life in consulting.  But, instead of waiting for scope creep to start, we should try to be proactive and limit the scope creep as much as possible.  Like at the buffet, the customer/client just gives you a couple hundred thousand dollars, or $16.99, and then expects a certain product in return.  In the case of software development, you should have a set of requirements for what you are doing and this should be agreed upon between the parties.  Both parties should know what they need to put in (time and effort for the firm and money for the client) and have an understanding of what they will get at the end.  In between the time that the agreement occurs and the delivery, is when scope creep can derail your project.

How should we manage scope creep?  Who should manage scope creep?  Why is scope creep important to be aware of?

Incomplete or inaccurate definition of the project requirements: It takes both parties to ensure that the requirements of the project will satisfy the client’s needs are within the agreed upon contract.  The client wants to make sure they get everything they want in their website and the firm wants to make sure they are able to earn a solid margin based on the costs to deliver those requirements.  If the requirements are inaccurate or incomplete, both parties can suffer.  Thus, the importance placed on ensuring detailed and comprehensive requirements is paramount.  All members’ of the project should be help accountable for this.  The level of detail often required to successfully complete a project is huge.  If the whole team is not involved in the gathering of requirements and digesting them, then scope creep could become an issue.  It is inevitable that requirements will be missed, but instead of waiting to find out what has been missed, get more detail than you think you need.  If an issue comes up about a missed requirement or an incomplete one, deal with it immediately.  Do not let it sit and fester.  Festering will only allow the client to possibly change the requirement again or even make the requirement more complex than initially thought.

Poor communication between parties: Communication is important throughout the software development life cycle and often times scope creep can be attributed to poor communication.  In one case, the poor communication was between members’ of the clients’ team, but it spiraled down to the project team at the firm.  One person at the client agreed to one thing so that was determined to be the requirement.  At a a later date, after documentation has been signed-off on, another person on the clients’ team decided that the requirement should be different.  They did not realize that the requirement had already been agreed upon and scoped.  The communication breakdown here was not just between the client, but also between the client and the firm.  We needed to have ensured that all members’ at the client site understood what signing-off on a document meant and what the process was to be if there were going to be changes.  Often times, it seems as if the client does not understand that just because they paid a certain amount of money, does not then mean that they can make changes at will until the project is complete.  The cost was developed based upon the agreed upon requirements and a change to such will likely impact at least the budget, and possibly the time line.

Weak project management: Project management ultimately owns scope.  They own the requirements for the project, the time line, and the budget.  Although they surround themselves with people who help out in each area and may even know about the specifics in the area, they are the ones who ultimately need to take ownership for the project and all things related to it.  A weak project manager can experience scope creep when they fail to communicate (yes, this ties in to the one above) to the client why something is not as easy to change as just sending an email saying you want it changed.  Project management needs to own the relationship with the client where they explain the consequences of changes and how they may impact the project.

Lack of solid change control process: A change process should include the change, why the change is needed, and the implications of the change to project budget and time line.  The client needs to understand that not all changes will impact budget and/or time line, but they need to also understand the opposite, that proposed changes can severely impact both budget and time line.  Change is often not free.  Although some firms will chose to do some changes in the form of a no charge change request, it is still paramount that the client understand that there will possibly be times when a change will require a change to the budget or the time line, or even both.  Thus, regardless of the level of effort, time, or budget that are required to fulfill a change request, it needs to be documented.  The client needs to understand at the onset of the project how change will be dealt with.  Throughout the project, all team member’s need to be acutely aware of the project’s scope and ensure they are not, without knowing, practicing scope creep.  It is always easier for a developer to say yes to the client when the change is small and they can make it quickly, but the client and developer need to understand that the process for enacting change will not always be so cut and dry or easy.  Thus, the importance of documenting all changes to the originally agreed upon requirements.

One final note on change requests as they pertain to the firm.  It is one thing for the client to agree to the change request, the impact to the time line, and the added costs, but it is quite another for the firm to not then properly deal with the request.  All too often, I see the project management jump all over the opportunity to get more business (which is a good thing, don’t get me wrong), but they do this at the expense of the original requirements and time line.  Management needs to understand that they may need to make further adjustments to the project aside from just collecting additional funds.  The time line may need to change.  Staffing may need to change.  Priorities may need to change.  There are a number of factors at play and they all need to be considered.

At a buffet the customer understands that they cannot sit there all night.  They understand that their payment does not mean they are entitled to take food home with them.  The requirements behind going to the buffet are clear from the beginning.  We will provide you with food.  Lots of food.  However, at the end of the night, you need to leave and you cannot take any food with you.  Obviously, there is no room for a change request here, but both parties are well aware of the requirements of their short-term contract upon handing over the money for the meal.

In order to ensure a successful trip to the buffet and a successful project, there needs to be a set of agreed upon requirements, solid communication and project management, and a well-developed plan for managing change.  Although this may not eliminate scope creep on your project, it should help lessen the impact that it has.