How to Manage Client Scope Creep

This post is the result of a good conversation with Abhishek at a recent event. 

He asked how we managed to ensure that there was no scope creep. My projects have usually been on track and within budget, and as Abhishek mentioned, client scope creep is one of the major reasons why large IT projects go out of budget or schedule. 

So, if you are a budding project manager responsible for client management, here is the secret to building great client solution and even better client relationships. 

Most client scope creep comes from 2 areas: 

A. Complex Workflows, where more approval levels are added. 

B. Reports 

The first thing you have to remember when dealing with client scope creep is that they are not trying to trouble you. Their intention is not the squeeze the juice out of you. Their intention is to do the best that they can for their company at the least possible price. 

Surprise! That is your intention too! 

Most vendor PMs do not understand this intention and objective synergy. But when you do, you realise that you and the client PM are on the same side, trying to do the same thing. 

The only thing is, we are using two different approaches to do it. 

So, Step One:

Establish Commonality of Purpose 

Sit down with your client and establish commonality of purpose. Both of you are working towards the same thing: 

A. Create the best possible solution

B. In the least possible time 

C. At the least possible cost

Once it has been stated, it appears intuitive. Yet, until we say it out and put it on the table, it is not so apparent to the other party. In fact, if you wait at the water cooler long enough, you will definitely hear the Project Managers from both sides cribbing. The Client PM usually says one or more of the following: 

• The vendor does not want to do any work or wants to do shoddy work and get away with it. 
• They are not doing enough KT 
• Even for small change they give such a huge estimate, and change request for everything! 
• They just don't understand our business and requirements. I don't know how to explain. 

The Vendor PM will usually say one or more of the following: 

• The Client is really miserly. 
• They always underestimate the time it will take to do something. 
• They are paying us for a cow and want us to make an elephant. 
• They don't understand how the system works. 
• They have such weird requirements! Who works like this? 

So, the step of establishing commonality of purpose is the most important one. It establishes trust and ensures that you row on the same direction, not in opposite directions. 

Once commonality of purpose is established, the next thing is to understand where scope creep is coming from. 

Step Two: 

Diagnose and Guide 

Most scope creep comes from the two areas I have mentioned above. You do your own diagnosis on your projects and understand WHERE the scope creep is coming. And then ask yourself WHY. 

What problem is the client trying to solve by doing this extra work? 

Let's get straight to taming the beast. 

Step Three 

Managing Scope Creep and Making Great Friends 

Here is the most important tip anyone will ever share with you on managing scope creep. It is so important that I am going to write it in caps. 

START WITH YES. 

Whenever the client asks you whether something can be done, NEVER start the conversation with No. if you know that it can be done, start with, "Yes". If you are not sure, start with "We will try to find a way to do this." 

Managing Workflow Complications

Most clients who try to add additional approval and exception workflows are basically trying to tame one beast - Compliance. 

That is the core objective. 

Start the conversation by saying - My work ends with doing the coding. Your work starts after that and goes on forever. So, my work is the shorter one. Let's talk about how this will work after go live in your business. Let's discuss a few scenarios and understand how much additional work it will add for your users, and what you are doing about it now. 

After that, listen. Let them explain all their use cases and exceptions. Understand their compliance needs thoroughly and most importantly, understand how users manage exceptions now. A system that can be excepted by the user in an emergency will eventually be excepted as a matter of course. The user's onboarding learning curve is slow, but their bypassing learning curve for any system is amazingly steep. So, if you make it necessary for users to bypass the system for one thing, they will be bypassing it for most things sooner than you realise. 

After the client has finished putting their requirements on the table, don your product specialist hat (or get your product specialists on board) and design a solution that meets their needs without being overly complicated. I can assure you that most workflows can be simplified. 

Pro Tip: For each workflow step, ask your client: 

• How will this step increase the transaction load of the user? 

Let's understand this with a real life example: 

Let's say that the client wants all travel to go to the department head. The questions we ask then are: 

A. How many travel requests will the DH have to approve in a day? Week? Month? How much time will it take them to approve each (assume reading time). If we go with 5 a week and 5 minutes per TR, that's 25 minutes of extra work per week. For an already stretched executive. 

Next, ask them how they plan to manage situations that are definitely going to arise - the executive on leave, too busy, traveling himself, etc. 

Usually, in such cases, a thing called Delegation of Authority is used. 

Let the client think about that. And then help them understand how to balance compliance with minimum transaction load on the users. 

• What value is this step adding to your process? 

The most frequent response to this is "It gives us better control" or "Compliance." 

Do not resist. After the client says this, sit back in silence and let them think. 

If they do not appear to be making headway, ask gently, "Are you creating a better process, or are you helping someone do CYA? Think about that. If the system can be hacked, it will neither lead to better compliance nor control. Every new control element you put in there is also a hacking opportunity. Think about the real business value of every step. And its real objective." 

Always be mindful of the client's imperatives. 99% of the times, clients see the difference between business value and CYA. But some cultures are necessarily CYA cultures. In those cultures, you can only help the client by perpetuating the CYA culture. Do that. 

And most importantly, NEVER disrespect the client - neither in public with your team, nor in private in your head. A Lot of delivery managers and PMs get together to laugh at clients in private. The client does not know tech as well as you do, and you don't know business as well as they do. Further, respect cannot be faked. Come from a place of real understanding, and you will create synergy. Come from a place of negotiation, and you will create a tug of war. I am still in touch with client PMs who worked with me 15 years ago, and more. 

Managing Reports 

Report requirements are the biggest headache for most PMs. The client wants to extract every element of data being put (or not put) into the system in about 15 reports on average (that's a joke, not a statistic). 

So, how does one tame the report monster? 

There are, once again, 2 simple questions that one asks the client. 

Since I have dealt with dashboard design and report management in another post, will just quickly state the 2 questions here: 

A. Who will enter this data? 

Request the client to go through their entire data flow process (you can use a proprietary methodology I have listed elsewhere on this blog - the Data River Diagram) and have them understand how the data will flow into the system in the first place. 

Is there enough reliability of that data for us to use it in reporting? 

B. What decision will it aid / How will you use it? 

Every pixel on an executive dashboard is important. Every second of executive time is important. If a data element is making it to reporting, it must help the user do one of the following: 

A. Monitor and control 

B. Diagnose and Correct 

C. Predict and Decide 

If the report is not fulfilling one of these 3 objectives, it should not be there. 

Your clients will truly appreciate your trying to create reports and dashboards that are relevant for the long term. 

In fact, invest some time in creating a report library that you know helps other organisations create effective dashboard and reporting interfaces, then proactively share it with clients. Will significantly shorten the cycle time and will also help the client see value in your work. 

So, are there any best practices that have helped you deliver better business value to your clients? Do share! 

How to Design a Dashboard for a customer

 

1. Do NOT sell flashy stuff for the sake of appearing “trendy” or “up to date” . “Up to date” gets dated pretty quickly. Useful, on the other hand, usually endures.

 

2. Use common sense more than you use the solution vendor’s marketing material.

 

3. Ask a few questions:

 

A. What are your categories of users? (Line managers, Middle Managers, Top Management, HR Business Partners, HR Senior Managers, Finance Managers..)

 

B. Do the information needs remain the same through the year, or do they change according to your time of year (financial year end closing, Appraisal year end closing, quarter end closing of sales…)

 

C. What is the top DECISION SUPPORT information that you need? no less than 1, and no more than 8. For each category of user. Gather this information using questionnaires divided by user category. Arrive at the top (by mode) answers and finalise them.

 

D. How often does this information change enough to impact ur decision making? (Eliminate all information that does not change significantly for a month or more. e.g., gender diversity is a statistic that will not change for the rest of the year, except during the campus recruitment season, when we need to actively monitor if we are hiring enough from each gender)

 

The second use of this information, is to determine the refresh rate with the database.

 

E. Do you want the dashboard to be the opening screen, or do u want to access this on need basis? (Tells you a lot about the actual usage of the dashboards being designed) . Please get this information, again, by category of user, then determine. Some categories may want it to be the first screen, others may want more than one dashboard that they access on need basis.

 

F. NOW, go to the flashy stuff – the look and feel.

 

What is the process you would like to follow, as an Analytics consultant?

 

 

 

Predicting Employee Attrition Using Big Data

 

2 weeks ago, the HR Head asked me a question – I want to know which employee is going to put in his papers – and when.

 

It was one of those rare moments when i was completely, totally stumped.

 

Here is a partial answer- How to use Big(and small) data together to predict employee turnover.

 

Factors that impact turnover

Lets start at the very beginning. What makes an employee quit?

 

When I conducted Exit interviews at our small 700 people IT organisation, i wouldnt ask them, “why are you leaving?” I would ask, “Why did you start looking?” I wanted to understand where the distance began, and why. The resignation is not what we are investigating. That action is the result of a disengagement that began weeks, months, even years before the actual resignation.

 

We are investing that disengagement. And the probability of its resulting in a separation. Two different things.

 

How do we measure something as intangible as disengagement?

 

I believe we may have some ideas here.

 

Pointers to Disengagement

 

• Employee Satisfaction Scores

This one is apparently a no brainer. Yet I am suprised to see that most ERP packages dont have a place to store the employee’s engagement score and compare that year on year. Then check for its correlation with their performance ratings and other behavioral actions. There are pointers there.

 

• Social Media Activity

This is where big data comes in. Have an internal IM program and an internal social media platform like yammer or internal discussion boards? Let your Big Data analysts do quick calculations on how often and with how many colleagues the IM was used. And how often the social media platform and discussion boards were used. Engaged employees will use more “connection points” to connect with the organisation and its people.

Notable Exception: Introverts. Introverts are people too. And they wont use Social Media. The end of this post says “Its the pattern, not the static data.” Read that section to know more.

 

• Meet the Parents

This is one of my favorite metaphors. When they bring the family, they are engaged. No exceptions. This also can be automated. Attendance at the family events is automated and can be fed into the giant supercomputer for automatic analysis. If you know when they stopped bringing the family, you know when they started thinking out.

 

• Access Card Patterns

Another big data beauty which needs individualised reading to make sense. How often was the access card used to go in and out? Whats the pattern? Has it changed lately?

 

Which access cards are used together? Are the breaks in groups, with one or two friends, or alone?

 

• Use of development resources on the learning portal

What kind of courses are being accessed? What was it earlier? Is it consistent with the expectations of the current role? What is the usage pattern?

 

• Correlate with Performance Ratings and the moneys

The higest risk categories are employees who have recently witnessed a fall in the rating, or whose difference from their maximum potential earning is very high. Let me explain. Suppose Mr. Alpha is paid INR 100 at the highest paying company. You are at the 60th percentile as an organisation, so you pay INR 60 for the same profile. But suppose the actual salary of Mr. Alpha is not INR 60, but INR 55, because of your internal compa ratio adjustments. Which means that Mr. Alpha is at a 45% discount from his maximum earning potential. That kind of gap is not sustainable.

 

And lastly, remember, its the pattern, not the static data. Big data will, over a period of time, establish patterns of behavior for each employee. When this pattern of behavior changes in a perceptible way, and for a consistent period, you know you should care enough to investigate more.

 

Does disengagement always result in attrition? Is it worth bothering with if it doesnt lead to attrition? What are some of the other pointers that can be used to arrive at behavioral disengagement? Anything we have missed out in the article above?