Tag: Stakeholder

Oh…How I Wish I Knew This Before!

Written by Praveen Udupa on February 4, 2014. Posted in Articles.

A few years ago, I had shifted with bag and baggage to the US. I thought that the upcoming project would consume me for at least a couple of years. Alas, that was not the case. I returned home in five months. Well, I don’t even want to begin to think about the financial and emotional set back that my family and I had to endure!

Why did this happen? The easy answer is always, “Oh! you know, the customer was totally ill-prepared. They did not even have the business case for the project and they had already spent $1M+. Can you believe that? Ultimately the CEO found out that there was no business case and revoked funding.” But this was only one of the reasons. There were several others. Among the others, one of the reasons was, well, me! I might have been the reason for the project getting scrapped!

You see, like in every project, there were two critical stakeholder roles for this project – the Sponsor and the Solution Owner. The sponsor was the head of IT. He controlled the budget. The solution owner was a director of a business division and he controlled the solution’s features. In most projects, these two roles are played by the same individual. But in this project, these two roles were played by two different individuals.

The PM, the Solution Architect and I were clear – go to the sponsor for budget, estimate approval, release plan and timeline. “Please the sponsor” was our motto. We went to the solution owner only for requirements sign off and kept him out of the loop for discussions on release planning. Here lies the problem!

These two individuals acted based on completely different set of motivations – having just got out of the debacle of a long drawn, several times over budget project, the sponsor wanted to show quick wins by having shorter release cycles, which meant that the budget per release was very limited and thus the features we could accommodate in a release was limited. The solution owner, on the other hand, maintained that each release should be of value to the end users. There is no point in releasing something which the end users would find unexciting. For him, the definition of quick win was not just to make a release, rather to make a release that would win accolades from the end users.

You may imagine what happened next – the sponsor and the solution owner never saw eye-to-eye. That they belonged in two different organizational units and did not have to regularly communicate with each other only exacerbated the situation. I would work with the PM on developing a release plan, estimates and project plan. We would then take it to the sponsor. He would look at it and instruct us to reduce the number of features and hence the estimates. We would do that. He would then approve the release plan. I would then go to the solution owner, who would look at the release plan and literally go ballistic. I would plead helplessness and indicate that I was at the mercy of the sponsor. He would care for none of that.

Eventually, I raised both my hands. I said, you guys work with each other and resolve your differences. Well, I’ll tell you something. They did resolve their differences. They had the project scrapped!

Was it my problem that the sponsor and solution owner did not get along? Is there anything that I could have done better? For both questions the answer is a resounding “Most certainly!” If only I had anticipated this tussle between stakeholders! If only I took a more proactive and a hands on approach to diffuse the tension between these two stakeholders. If only, if only…now do you get how I was one of the reasons for the project getting scrapped?

What could I do better? Stakeholder Analysis is a best practice that every BA must have mastery over. Alas, I studied this concept only after I returned from the US feeling like a hapless victim.

The purpose of stakeholder analysis is to analyze the interest and influence of each stakeholder and customize our collaboration strategy with each stakeholder with the sole intention of minimizing the adverse impact on the delivery of the solution.

Stakeholder Analysis enables the BA to deal with stakeholders as a matter of choice rather than chance!

So, let’s talk about stakeholder management:

Who is a stakeholder?

Stakeholder is anyone who is directly/indirectly, positively/negatively impacted by the problem and/or its solution. It is possible that someone is ‘positively’ impacted by the problem, in fact they might thrive and flourish inside the problem.

What is Stakeholder Management?

Stakeholder Management is about customizing collaboration strategies to suit the temperament and background of each stakeholder with an intention to “minimize the any adverse impact on the progress of a project” that could caused by a stakeholder.

Step 1: Stakeholder Identification

The first step in Stakeholder Management is obviously identification of all stakeholders. This activity begins as soon as the business needs are identified.

It is important, well, to make sure that all relevant stakeholders’ views have been considered in building the solution. The BABOK lists various stakeholder roles that can be used to identify stakeholders. But this is easier said than done. For example:

Consider the stakeholder role ‘Regulator’. Most of us assume this to be the macro regulatory bodies like SEC, SEBI, FDA, TRAI, IRDA, FSA, etc. But somehow we forget that PMO of an organization is also a regulator – they regulate what, how and when project deliverables need to be produced.
Consider Enterprise Security team. They regulate access to all ‘Applications’ in the enterprise, including the one that you are defining requirements for. Not only that, they also dictate security related requirements.
Consider Sponsor – the one with the money is the sponsor. We all know that. We assume that the sponsor needs to be pleased all the time. Well, this is not true always. It is not JUST the sponsor that needs pleasing…there are other stakeholders. One of the most critical stakeholders that need to be closely managed is who I call “Business Owner” a.k.a Solution owner. (The BABOK does not call out a separate stakeholder role called solution owner. I assume they include this in their Domain SME.) The Solution Owner decides what features and functionality should the solution provide and also has a say in release planning (i.e. when does which feature become available in the solution. Fair, right?) Normally, there is one individual that sits in the roles of both Sponsor and Solution Owner. This is the best case scenario. The troublesome scenario is when these two roles are played by two different individuals, like in my case (described earlier).

Step 2: Stakeholder Analysis

The second step is stakeholder analysis. This comprises of two parts – understanding a stakeholders ‘interest’ and understanding a stakeholder ‘influence’. Let me dwell on these two points:

Stakeholder Interest
It is important to understand stakeholder’s interests because it gives us some indication on how much would the stakeholder care about exercising whatever influence s/he might have. Interest is a function of two factors – change appetite of the stakeholder and impact of the solution over the stakeholder.
- Change Appetite is the disposition of the stakeholder towards the change. In other words, to what extent is the stakeholder willing to change.
- Impact of the solution is to what extent will the solution force the stakeholder to change
Stakeholder Interest is determined as follows:

Notice that if the Change Appetite is Low and Impact of Solution is High, the stakeholder will have a NEGATIVE interest in the project, which means that the stakeholder will not hesitate to scuttle the progress of the project or even kill it, provided s/he has adequate influence.
Stakeholder Influence
Stakeholder Influence is very simple. It is the degree to which the stakeholder can sway decisions to his/her line of thinking and impact the outcome of the project.

Step 3: Stakeholder Map

The third step in Stakeholder Management is to develop a visual model of stakeholder’s interest and influence, which is called a stakeholder map. It looks like this:

Each stakeholder gets assigned a quadrant, with the relative location in the quadrant indicating the extent of influence / interest of the stakeholder compared to other stakeholders. The RED circles indicate the stakeholders who have a negative interest.

“Okay…this is great”, I hear you saying. “Now what do I do? What significance do these quadrants hold? What is this about one stakeholder Bob moving from one quadrant to the other?”

A stakeholder map is the four quadrant Interest vs. Influence map. All the stakeholders fall into one of these four quadrants.

What do these quadrants represent?

The I Quadrant (top right) carries the most significance because the stakeholders who are high on both Interest and Influence are bracketed here.

But, mind you, the folk with negative Interest (the RED circles) can appear in the I and IV quadrants only…guess why?

What do I do with this map?

The stakeholder map essentially helps the BA figure out how the collaboration with the stakeholders should be.

I Quadrant – Manage Closely

High Influence & High (Positive) Interest

Work in Collaboration/ Partnership and keep on board.
Manage them closely and maintain support
Refine communications to align with project goals.
Leverage stakeholder influence.
Use in project teams to deliver change.
Reward their support.
Use an interactive communication method – do not use a dictatorial tone with them. Make them feel that every idea is theirs

High Influence & High (Negative) Interest / Resistance

Build Relationships when possible. Take time to know them.
Understand the underlying reasons for resistance. Paint a picture of the future if things continue as is.
Acknowledge their concerns.
Compromise on strategy where it is possible – give and take negotiation
Stand firm on principles and the need for change
Involve other influencing people who are more positive in influencing them
Use an interactive communication method – do not use a dictatorial tone with them. Make them feel that every idea is theirs

II Quadrant – Keep Satisfied

High Influence and Low Interest

Keep them satisfied.
Send regular information about project but not constant involvement.
Ensure that they support the project.
Target communications to align with project goals.
Provide information to help them become supporters
Enthuse about change and sell the benefits.
Use an push communication method.
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence

III Quadrant – Keep Informed

Low Influence and Low Interest

Manage relationship passively – not necessary to seek them out. Be courteous and genuine when they pass by the hallway or in the cafeteria
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Use a push communication method – no interaction unless asked for.

IV Quadrant – Monitor

Low Influence and High Interest

Consult or have a dialog
Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
Empower them and protect their interests
Consider their advice and opinions…no need to bend backwards to accommodate, unless they are really important to the project
Remain in constant communication to ensure that no major issues are arising

Coming back to my situation

So, had I known the above stakeholder management method, rather, had I known its real significance, I would have realized that both my warring stakeholders – sponsor and business owner – fall under the I Quadrant. In hindsight, what could have saved the project is the following collaboration strategies:

Involve both the sponsor and the business owner in all status review meetings (I used to involve only the sponsor)
Facilitate communication between these two stakeholders to ensure that both of them truly understand each other’s worlds and both realize that neither is acting with any vested interest, rather, both want the best from the project
Arrive at the Release Plan together, such that both stakeholders’ interests are optimally taken care of and that both understand what they are giving up, if at all, and why
Create an atmosphere of trust that neither stakeholder give you any guidance/direction without the knowledge of the other.

Well…better late than never, right? I might have been partially responsible for losing the project, but I did learn a lesson from that.

Let me know what you think…

Don’t forget to leave your comments below.

The Value of a Business Analyst on a Bring Your Own Device project

Written by Marc McCready on January 28, 2014. Posted in Articles.

I’m confident enough about the role of the Business Analyst to say that a good BA can add value to any ICT or process improvement project. At first, the prospect of my first BYOD project had me questioning the amount of value I could add, after all, the project would surely be more about technically managing the device than delivering end user functionality?

Having just completed my first BYOD project (and as part of the course, questioning the value I was adding throughout), hopefully I can demonstrate from practical experience the value a BA can add to one of these projects:

Defining the business need; the need often involves cost reduction, which is a without doubt a valid need as mobile costs represent a significant proportion of most CIOs budgets, but is an area to be careful with if that is the sole driver. A BA can add value here by questioning further to identify if there are any other problems with the current mobile service(s) e.g. low user satisfaction due to outdated technology constraining the way they work, increased employee mobility, risk associated with the viability of particular technology providers in the marketplace etc. This will help establish a broader base and help with identifying other sources which can realise benefits.
Considering solution options; BYOD is just one option, there are plenty of others, depending on the business problem being faced e.g. re-negotiating existing corporate fleet contracts, upgrading the current corporate fleet may be another, or trimming back who’s entitled to a corporate mobile device…there are plenty more! The BA can add value by considering a full range of solution options and considering their advantages and disadvantages objectively to ensure BYOD is the most viable solution.
Defining the Business Case; this took longer than the average Business Case due to the complexity associated with mobile service costs, so factor this into your planning. The BA can add value here by ensuring that all the costs and benefits associated with BYOD are factored in, and that any perceived cost savings can be established based upon realistic assumptions. If the financial justification rests on a particular volume of employees switching to BYOD, consider doing some market research to de-risk your estimate.
Defining Business Requirements; stakeholder identification is key. The obvious choice are the IT users that will manage the devices, but don’t forget about business users just because the software solution won’t be used by them. The business processes they execute are a source of requirements too, as it will enable them to use mobile devices to support some of their process steps e.g. taking photos. Also, if you are migrating users from a corporate fleet to BYOD, the BA can add additional value by designing the transition process for employees. This process will be used by the Implementation Team to define a set of instructions for users to follow, so it’s a crucial one to get right!
Defining Functional Requirements; functional requirements were initially difficult to elicit because the IT users had not practical experience of managing personal devices in a corporate environment. The BA can add value by using scenarios (which may have already been created to validate processes) to help identify and generate the use cases initially, and then cycle back through to ensure the use case can satisfy a number of scenarios.
Defining Service Requirements; a key consideration is whether the organization has an IT Help Desk with the capability to support BYOD. The range of devices, and rapid development and deployment of mobile operating systems can be a daunting prospect and outsourcing to a mobile specialist is a key consideration. If this is the case for your project, the BA can add value by defining the services and service level requirements the organisation will require from a service provider.
Solutions assessment & validation; the Mobile Device Management vendors can deliver some slick demonstrations; the BA can add value to this process by remaining objective and ensuring the functional requirements can be met!

Hopefully this tells a compelling story of how a BA can add value on a BYOD project. The project in question had a successful implementation, and is currently on track to realise the majority of the benefits defined in the Business Case.

Don’t forget to leave your comments below.

Turning Competing Stakeholders into Collaborating Product Partners

Written by Ellen Gottesdiener on November 19, 2013. Posted in Articles.

On time. On budget. Error free. These are crucial delivery goals for any organization. Yet they are rendered almost meaningless if the product fails to deliver value.

That’s why successful delivery teams work hand-in-hand with their stakeholders as product partners, defining value and then actively discovering — and delivering — high-value solutions. This goes beyond feature requests and requirements documents—beyond user stories and product backlogs—beyond the push-pull of competing interests. It’s a partnership where the ideas, perspectives and experiences of three different stakeholder groups converge. The result? Product partners who collaborate to discover and deliver value.

Let’s look more closely at these product partners: who they are, how they work together, and how they balance competing priorities.

First Ask Who

A product partnership includes people from three realms: customer, business, and technology. Each offers a unique perspective and has its own ideas of what is valuable.

The customer partners represent users, buyers, and advisers — people or systems that interface with the product, choose to buy it, or influence others to buy it. They tend to value improved productivity, heightened efficiency, greater speed, entertainment, and similar benefits.

Business partners represent the people in your organization who authorize, champion, or support the product or who provide subject matter expertise. They find value in improving market position, complying with regulations, achieving a business case, reducing overhead costs, enhancing internal performance, and so on.

Technology partners (your delivery team, internal or third parties) design, deliver, test, and support the product or advise those who do. They may value building a high-quality product, offering smooth, continual delivery, adopting a stable architecture, and the like.

Figure 1: The Product Partners
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

This mix of partners and perspectives is essential, no matter what kind of delivery method you adopt (agile, traditional, hybrid, or another approach). For the partnership to work, these three disparate groups, with specific individual titles and roles, must collaborate to reach their shared goal: discover and deliver value.

Partners don’t see themselves as dependent or independent. Instead, they’re interdependent — mutually reliant on and responsible to each other to reach their shared goal. Acting as partners, they apply their skills and knowledge without regard to their title or role. The lines between product and project management, business analysis, testing, user experience, quality assurance, and development and operations blur.

To Discover, Ask Why

Once the product partner team is identified, the product partners work together to discover which product attributes will deliver value. The key to successful discovery is to keep the focus on value—the why behind each product option. To ensure that all of the product partners understand what is important to each group—each partner’s value considerations—we often find it helpful to write and post the different value considerations in the group space. Business partners, for example, often find that they identify with the acronym IRACIS (“ear ras cuss”). “IR” stands for “increase revenue,” “AC” is “avoid costs,” and “IS” means “improve service.”

When shared openly, IRACIS and other value considerations become a vital reference point as the partners weigh the value of the product options. As their perspectives and value considerations diverge or compete, they use participatory decision making to reach closure.

To Decide, Ask When

One factor that has tremendous influence on this decision-making process is when. Asking when helps the partners decide the opportune time a product option will deliver its greatest value. We categorize the product’s planning horizons as the Big-View, the Pre-View, and the Now-View.

The Big-View is the long-term view or product roadmap (one or two years).

The Pre-View focuses on the next product iteration or release (a month or two).

The Now-View concentrates on the next product increment (a few days to a month).

The length of the views may vary. One team’s Pre-View (release) might be 2 weeks; some teams (newer to agile and automated testing) have 3 or 4 month release cycles.

Figure 2: The Product Partners
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

The product partners typically need the most the valuable options to be delivered early in the product’s lifecycle, so when weighing competing product options, they allocate higher priority ones to nearer-term planning horizons. Because the value of a product option can change over time, the partners benefit from having the flexibility to allocate and deliver options at the last responsible moment.

Choose How to Collaborate

It’s not enough to get the right people together and ask the right questions. To communicate efficiently and effectively about how to deliver, product partners need a focused way to communicate and make decisions together. By far the most efficient and effective discovery mechanism is a collaborative approach called the “structured conversation”. In a structured conversation, the product partners first explore possible requirements (options) for their next increment. They then evaluate these many options in terms of value. Once they have narrowed the list of options through the evaluation process, they confirm how they will verify and validate these candidate solutions with unambiguous acceptance criteria. The validation includes how to test that they delivered the right requirements, and that they achieved the anticipated value from each delivery. You can learn more about structured conversations here and in this 7-minute video.

Figure 3: The Structured Conversation
Image Source: Discover to Deliver: Agile Product Planning and Analysis, Gottesdiener and Gorman, 2012

A structured conversation is a lightweight yet disciplined approach to ensure that the team members learn from each delivery increment, gathering feedback and improving their product and process as they go. When the conversation’s scope is the longer-term aspects of the product, a facilitated workshop is a powerful way to discover the product’s big picture.

All Together Now

True success depends on discovering product value and delivering it. To do this most effectively, you must abandon the mindset of competing stakeholders and instead embrace the concept of collaborating product partnerships, where role and title take second place to perspective and value. By actively engaging as product partners in structured conversations–exploring, evaluating and confirming product options–the stakeholders ensure every product increment delivers the highest value. Their active collaboration also yields a stronger community with effective communications, shared understanding, increased productivity and trust.

To maximize the effectiveness of your product partnership, keep these points in mind:

Include people from the customer, business, and technology realms.
Have each partner or group describe and share its value considerations.
Frame value decisions within one planning horizon.
Hold structured conversations to explore and evaluate product options, and to confirm candidate solutions.
Promote interdependence among the product partners. Remember, it’s the goal, not the role.

Don’t forget to leave your comments below.

The Bermuda Triangle for Projects

Written by Ieuan Wickham on November 5, 2013. Posted in Articles.

We all run afoul of this from time to time – it’s known as the Project Management Triangle or the Iron Triangle. It encapsulates the tension between schedule, cost and scope that occurs on any project, and it appears in a number of forms. Over time, as the Wikipedia article demonstrates, people have explored how it’s not quite that simple. In constructing a house, for instance, you can still achieve the essence of the scope of the project (e.g. all the rooms) in fixed time and cost by sacrificing quality (e.g. a formica bench instead of granite, or cheaper carpet).

It is also a critical factor in how we as Business Analysts prioritise business, stakeholder, or solution requirements. For each requirement it should be possible, if you are so inclined, to measure time and risk and cost and the value delivered by the scope of the requirement. In practice, prioritisation is typically done by a subjective stakeholder agreement session.

Understanding What’s Wrong

The Iron Triangle reaches its nadir in the phrase: ‘Fast, cheap, good – pick two.’ I have two issues with this sentence.

The first issue I have is that it encourages the idea that it is always possible to actually complete a large project on time and on budget. (That’s not what it says, but it is how it’s interpreted.) Sadly, for most Information Systems (IS) projects this is more due to good fortune than good judgement or hard work. The second issue is that ‘good’ is interpreted as referring to quality rather than scope. A while back I worked on a project where the stated priorities were time, then cost, then quality – “but we’re not sacrificing quality at all”.

Here’s why I think having an Iron Triangle of time, cost, and quality is a bad idea on an IS project. Scope in this context is implicitly fixed, even if it’s not fully understood. But when we sacrifice quality, what we’re actually sacrificing is uncontrolled scope. This is because quality usually degrades unevenly across the scope of the project, although it may degrade more in specific areas. If a piece of software has poor quality, it means it doesn’t do the job that’s being asked of it to the standard required by the client. I don’t mean that the solution must instead be perfect; rather, that it should meet the agreed and accepted quality targets. If it doesn’t then the client will not accept the solution, either actively by rejecting it or passively by not using it.

For the example below, imagine our scope as a list of 100 requirements, grouped so that requirements near to each other are part of the same scope area. As the project proceeds, analysis uncovers 10 additional requirements, which we insert in their appropriate places in the list. This causes the scope to expand.

Figure 1- time, cost and quality.

Figure 1 demonstrates what happens if we sacrifice quality. At some point (usually late) during the project we find out that due to poor quality, the requirements will be incompletely met across all requirement groups. The solution doesn’t work, and it’s not going to work within our ‘hard’ constraints of time and cost. To deliver a complete solution we now have to choose whether to:

allow an increase to time and cost, i.e. overrun the project, in the name of delivering the expected and agreed scope;
make scope cuts to meet the budget by stopping work on some of the groups of requirements, against the backdrop of an expectation that the full scope will be delivered;
or, more likely, both.

What We Can Do Better

Figure 2 – time, cost and scope

In contrast, Figure 2 shows the result of sacrificing scope. As analysis proceeds we determine early that we won’t meet the budget, because our understanding of the size of the scope has increased. We reduce the scope in agreed areas as early as we can. This allows us to manage the savings that we need to continue to provide the best value, instead of being driven by the quality of the delivered functional areas. It also allows us to set expectations early about what scope will be delivered, and what workarounds or alternative solutions might need to be put in place.

When we get the opportunity to work with stakeholders to determine how we define project success, project sliders can be useful. I prefer to use sliders in such a way that no two sliders can be on the same setting. This means you need as many settings as you have sliders, but they prevent someone from setting time, cost and quality as 5 and everything else as 0, for instance. This isn’t a problem that we fix with tools, it’s about education and setting expectations. And sometimes we’re just not in a position to influence these attitudes.

When we’re working with stakeholders to prioritise requirements, we need to encourage them to think clearly about what their priorities are, and the implications of setting those priorities given the funding and schedule. We also need to make sure that the stakeholders can trace the requirements to their relevant benefits and understand the relevant costs, benefits, risks, compliance aspects, or whatever factors they have agreed to be used for prioritisation.

For example, using MoSCoW priorities:

If it’s a Must-Have, then if we can’t find a solution, we need to reconsider the project viability. (Are you sure it’s a Must-Have? Does the business value of the requirement justify this?)
If it’s a Should-Have, we’ll do it if we have time and budget left over. (What are the relative priorities of the Should-Haves?)
If it’s a Could-Have, then we’ll only do it if it’s effectively free.

We need to do this whenever we’re deciding which requirements to proceed to the next stage with. For a Scrum project, this might be at each sprint. For an iterative project, this might be at the end of the stakeholder requirements analysis and the end of the solution requirements analysis for each iteration.

If instead the stakeholders persist in talking about time, cost and quality, it encourages them to think of scope as being fixed and the ‘everything’s a must-have’ mentality. It makes it harder to admit that they need to make the tough call early, and either increase schedule or cost, or decrease the scope. When they finally need to make the call, it’s more expensive and they have fewer choices.

That’s when the stakeholders need to admit that they didn’t have a priority of time, cost and then quality. What they actually needed was the ability to make transparent and informed choices about changes to scope, cost, and time. We as Business Analysts contribute to this by performing sufficient requirements analysis to identify those prioritisation factors, and by encouraging stakeholders to review their prioritisation at the right times.

Don’t forget to leave your comments below.

How to BUSINESS Analyze Stakeholder Requirements

Written by Marcos Ferrer on September 3, 2013. Posted in Articles.

Many BAs ask me where to get the business requirements when no one has done Enterprise Analysis or even a simple “Business Knead”. “That stuff is above my pay grade”, they say, “and even if it weren’t nobody gives us enough time or information about what is really going on. We barely have time to clean up today’s mess, never mind tomorrow’s.”

“Me three” is my reply. My experience and certification don’t change basic human nature. Even when I am invited to high-level meetings, no one thinks of me as a “business owner” or manager. The checks are written above my head, and many command structures still insist on top down flow only.

Stick with us (thanks to my anonymous class, who inspired months of blogs) as we transcend BABOK by explaining how (and why) to get something from nothing , and in the process raise your pay grade*.

Last month we tried to use ordinary analysis to break down stakeholder requirements driven by the need to cut costs, resulting in something like:

1. Internal Service Costs

Total Costs of Internal Service by Organizational Structure
1. Costs by Service Provider Department
  1. Costs by Service Provider Team
    1. Costs by Service Provider (???time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
2. ???Costs by Service Recipient Department
  1. ???Costs by Service Recipient Team
    1. ???Costs by Service Recipient (time/effort)
    2. ???Other incidental costs (overhead/supplies)
  2. ???
3. Costs by Service Type
  1. ??? On boarding
  2. ??? Annual Training
  3. ??? IT Help Desk
  4. ??? HR Guidance
  5. ??? More…
4. Costs by Chances to Save Resources
  1. ???
  2. ???
5. More ???Cost Views…
  1. ???
  2. ???

2. ???Internal Service Benefits

???Etc.
???Left as an exercise for the reader, similar to above yet different.

I was so tempted to expand this list of trees**, but I decided to take a peek at the forest instead. Why?

Although we have tried to expand the original stakeholder requirement, it is still unclear what is or isn’t a priority. The focus so far seems to be on WHO DID WHAT. The BABOK says that BAs have general business knowledge. What do you know about measuring or enhancing employee performance? What are the impacts of singling persons or departments out? Short term? Long term?

It is not clear how knowing how much internal service is being done by whom for where will change costs or improve the business. At best we could decide to re-train (or fire) the lowest performers, and we will discover that (by definition) there aren’t many of those, and once fired, someone else will take their place. There might be a few VERY high performers, but they will not be reproducible as a general rule.

How many Michelangelos does it take to screw in a light bulb? How many non-Michelangelos does it take to paint a masterpiece? It is quite likely that most employees are doing the best they can in the circumstances, with statistical fluctuations over time, but no significant performance differences.

Blaming (even identifying) the workers to reduce costs is an organizational dead end. Many great leaders reject the use of the “Theory X” approach” (workers are lazy thieves who are best motivated by whippings and emotional abuse). These include Robert Townsend of Avis (“Up the Organization” remains relevant to this day), Douglas McGregor of MIT, and especially Edward Deming (“brought to you by the nice people who made your nice car that you can rely on”) among MANY other quality triumphs. Deming showed that in most cases job performance is randomly distributed among employees over time, once inputs, policies and tools are established.

Another high-level concept worth knowing is that the tyranny of numbers is a risk in any project (“Hey, we are paying $10 per bug found!”). Cutting costs is not a business goal by itself. If it were, the best approach would be to cease operations entirely, achieving zero costs. Finance mavens will recognize that investing zero has “opportunity costs”, and there is no way out – figure out how best to use resources, or stick them in your mattress to rot.

This makes us realize that the stakeholder requirements are not remotely robust or useful as imagined. They represent a literal attempt to monitor internal service costs, perhaps in an attempt to “be fair” and “spread the pain”, with no clue how these costs relate to the business success.

If we pursue such requirements, we are likely to create a system to track internal service costs that has little or no impact on the quality of decision-making. Worse, it might have too much impact on the quantity of decision-making (“look, department D is giving too much internal service this month, let’s dock their pay to re-motivate them to reduce the service”).

SO, what is the real business need? Cost control obviously matters, but how does that “high level abstract not quite a requirement as stated” relate to possible actual requirements? Let’s use a “MOST” analysis (Missions, Objectives, Strategies, Tactics) and see if it helps:

Let’s agree (for this blog) that many organizations have “high-level” missions that are a little “generic”; something like:

Be Customer Driven
Make Quality Everyone’s Business
Practice Respect For All
Maximize Efficiency, Effectiveness and Profitability

This may seem fluffy and devoid of substance (it is** :)), but we can use it as a starting point to re-imagine the stakeholder requirements. It would seem that the mission to “Maximize Efficiency” is the primary mission in play. Leaving out “Profitability” is the easy to commit error. When I trace to this level some PMs (not you, not you, resemblance to real people is a coincidence) tell me “everyone already knows that, don’t waste your time.” In spite of any resistance, no one can forbid me to know the organization mission, and use the knowledge to add value to stakeholders.

This seems like pure “Root Cause” business need stuff. Root cause stuff can be sensitive to discuss, and requires tremendous diplomacy, facilitation and values (don’t blame people) to do well. That is a different essay for some other day. In an attempt to work with this group of “internal service” stakeholders we will pretend to analyze the reasons that internal service is TOO costly:Click image to view larger.

OOPS! Depending on the actual root cause analysis (mine is made up for the blog, can you spot the big error?) cutting internal services might hurt effectiveness and profitability.

What would you do? Don’t hold back, the future of the organization will be impacted one way or another.

Hmmm…is the problem the root cause analysis, or is there a deeper problem? What is the root cause of this rather un-useful root cause analysis? WHO CAN OFFER AN ANSWER? Will James marry Oneida or stay in Paraguay? Is anybody out there?

Have fun!

* Pay grade ≠ pay amount – negotiation is a key competency and worth a try :).

** Not ! 🙂

*** A higher quality mission statement might be “Balance efficiency, effectiveness and profitability”. Maximizing everything sounds good (and seems simple) yet is just as hard as “Balancing”. The word “Balancing” does not hide the deeper truth that tradeoffs are usually necessary and too much simplicity can mislead.

Don’t forget to leave your comments below.