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! 

Steps for creating an ERP PMO

 1. Scope : At what level do you define “Project” – at the module level, submodule level, or the entire implementation is one project? A lot of people use module, but it’s really a function of what a PM should be able to handle. Before you create what will be handled by a PMO, you have to be clear about what the PMO will NOT handle and should be handled by the individual PMs at their own level.

2. Span of Operations: Remember that a PMO is only ONE step above the PM. If you need program management, create a Program Management Office. If you are working on something even bigger, don’t hesitate to create a portfolio management team. Determine the complexity and the experience of a team, and then arrive at a considered decision.

3. Workflows: Determine workflows for decisions, escalations and status updates. At the very least.

4. Information Sharing: Determine what information will be shared with the PMO, by whom and at what frequency.

5. Rules and Authority to Decide: Who has the authority to decide? What is the quorum? For instance, can a decision about a module be taken if the module lead was not in the meeting? Can a release be approved without the change manager?

These should cover the fundamental setup of a PMO.

The Importance of KTB in RTB, GTB and TTB

 

As IT organisations grapple with budget allocations and portfolio assessments and redesigning the service portfolio to stay relevant in the digital era, they probably feel underequipped and over worked. Perhaps rightfully so.

The weekend ruminations were on helping CIOs deal with the portfolio management conundrum. Of all the ideas that floated, one stood out.

While we talk about RTB, GTB and TTB, and try to use allocations in these areas, perhaps it is time to invest in a crucial component. IMHO, this component is a key input in determining the IT Service portfolio of an organisation and yet one that receives very little attention.

Ladies and Gentlemen, presenting – KTB – Know The Business. Most IT organisations have dedicated staff whose only job is to monitor the latest IT trends in their industry and to map usage to their own organisations. They may be called by any name – Business Analysts, Functional Consultants, Center of Excellence et al. Sometimes, key employees do it as part of their regular JD.

But few, if any, invest in staying updated in whats happening in business trends around the world, and not just the IT trends in that industry. Better still, we do not normally find the IT folks very conversant with the details of how the business is actually run. Consequently, we have a situation where we are trying to decide the IT needs of a business but we do not know what that business is.

Endpoint: CIOs must invest budgetary dollars in ensuring that the entire team, or at least the portfolio management/ budgeting team is aware of how the business is run, and how it will change over the next 2-3 years (not just in IT).  KTB should be a part(albeit a small part) of the Portfolio Management budget.

Where Gamification Comes From – The Impact of Millennials in the Workplace

 The Background

This morning, I was at a workshop for parents at my child’s school. We were taught how to make spellings fun for our children. The class was very interesting, with activities and games to help children learn spelling.

At one point, the trainer said, “Our children have a very low span of attention. And this generation does not believe in work. So it is our duty to make learning fun for them. They will learn, but we must make it interesting and ..fun!  Our parents just asked us to learn spelling, and we did. But that’s not how this generation works.”

If the reality of the millennials had never hit me, it did now. The teacher was right – this is a generation that has grown up without the concept of “work”. If its not fun, if its not engaging enough, they wont do it. Suddenly, it is someone else’s job to make the workplace “engaging” and to keep them interested. Remember that famous quote ? The world owes you  NOTHING.? Apparently, the millennials skipped that one in their entire education.

Having said that, the generation is brilliant.. they are capable of creative destruction.. and reconstruction – probably more than any generation before them has been.  They have a very supportive social structure – more than any other generation has had since the Victorian age, at the very least.

The Problem Statement

So, how do we get them to contribute to the grinding mill called “normal work” . How do we get them to understand the concept of “work” ?

The Immediate Solution

Perhaps this explains the ever growing trend of “gamification” of everything. Today, we reward the smallest things – there are “tasks” and “quests” and “points (or eggs or coins or gems) to be won, then reused within the game for higher levels, more advanced digital tools and so on. I would like to make special mention of things like office Vibe, which rewards proof of collaborative behavior, healthy living, et al. There are a lot of other apps, websites and even custom developed tools that do the same.

The generation coming after them is not any different. Increasingly, “Work” becomes a dirty word.

As practitioners, we face a unique problem because of that..

The Problem created by the immediate solution

The colleagues who are not millennials, wonder why the new generation is so “pampered” , while they come and do an honest day’s job and are not rewarded as much as, or on par with their work contribution.

Cause Analysis

As I see it, these different generations derive gratification from different stimuli. As workplace practitioners, we try and provide these stimuli.

For the non millennials, the primary source of gratification is, by and large, how much and how well their work is done, the money they get for it, and the recognition they get for it. The output and the recognition for that output. Also, elements of discipline like being on time, communicating according to protocol et al. Make

For the millennials, gratification comes from “fun”, “enjoyment” and “being engaged”. Having control over their calendars, working out of anywhere, and getting recognised for output alone.

(Of course, these are sweeping generalisations being used to simplify and present the problem we are dealing with in this post. )

So, structurally, both groups are getting what gives them gratification.

The problem comes when we try to create an environment that rewards *both* these behaviors at the same time and also when people try to compare their contribution: reward ratio with that of the other groups.

Solving for the root problem

So, the problem is not just that the 2 generations view the idea of “work” very differently. It is also not that organisations are not willing to provide what they need to create a stimulating and engaging workplace experience.

The real problem arises because:

A. We pretend that we are treating all employees the same: We cannot. Because they are not the same. We are giving each one what they need – broadly. If one gets flexi time , it is because they need flexi time. if the other gets higher fixed bonus, it is not because we penalise flexi time and reward adherence to fixed time. It means that money is not the only kind of reward we give. Money is only one type of gratification. Flexi time and shorts at work is another. When we create this myth of equal treatment for all employees, we are also perpetrating the myth that basically, all employees are the same, they need the same things.

Solving for Perpetrating the Myth:  

To solve for this myth, we need to acknowledge that all employees are different and may need different things. Being different does not make them “flippant” or “undisciplined” or millennials”old fashioned” or “stuffy”. We don’t need to label anyone who is different from us. Labeling happens when acceptance is missing. And acceptance has to start with the employer. Acknowledge differences. Stop the “Everyone gets the same treatment” myth. Acknowledge that policies are differential, but the basis of differentiation is the need of that employee group.

B. People compare with each other.

Solving for Comparisons at workplace

Comparisons happen, mostly in linear reward structures – ones based mostly on money as the reward.

Suppose we were to initiate a multi factor rewards environment, where people could pick the things that work for them – flexi time, informal dressing, tele presence, travel, et al. Each element has a cost to company, and it is published.

Endpoint

We are dealing with multiple age groups at the workplace. We keep thinking of ways to make them work together. This is not THE answer. There cannot be one “THE” answer. But the more we work in this area, the more answers we are likely to have.

Visualisation: That crucial element for Agile in ERP

Once upon a time, we wanted to use Test Driven Development (TDD) on a small ERP delivery project. This would reduce documentation by 70% and lead to a time saving of upto 40%. We were very excited.

We ran the familiarisation workshops. Explained how the method will be different – to the customer and to our own development teams. Got everyone’s concurrence. And then we started with a small project in pilot.

 

Except, it didn't take off. But that experience taught me something really important about adoption of Agile in ERP projects. The missing link was simply this – because ERP (even small ERP deliveries) are huge, we were not able to visualise the end product. That is why we could not start with Test Driven Development.

 

Once we had the Root Cause Analysis, it was relatively easy. For the next application, I sat and visualised the ENTIRE application – all user types, with all their screens, and behavior of each button.

 

We didn’t have the luxury of standard screens that most ERP customers have – they know the standard screen buttons available to them and know what they look like. We had to visualise the entire application from scratch.

But here is the important thing – once the wireframing was done, it was much easier to do Test Cases. We simply knew what to expect!

 

So here’s the recommendation – when we try to do TDD, especially on non traditional areas like ERP, spend some time and expense on a soft skills trainer – and do a visualisation, wireframing workshop. For the business owner and users. If they can visualise what they want, the rest of the exercise becomes much easier. Today, I find Visualisation to be a really powerful element in application design.

 

And visualisation is a specialised skill. Usually, it needs to be learnt.