Operations, Tactics & Strategery

I’d like to focus on a topic that continues to come up and has been the source of debate in many companies. In this challenging economy, is important to continue to focus on delivering value to the business. Many organizations continue to re-align resources to meet the demands of their business. Business is complex, dynamic and changes daily. With all the things going on in the past couple months I’ve had to remind myself not to focus on all those other things, just focus on delivering value.

I’ve recently seen an organization re-invent itself to be more focused on core deliverables. Those deliverables have value associated to them which is aligned with the organization’s business objectives. The value behind those deliverables comes from a business case. The topic of much debate has been, what is a business case in relation to justifying and prioritizing product requirements that improve the customer’s experience. There was lengthy debate on business case and return on investment (ROI) and what those are and might look like. To be fair it is a difficult exercise, many people throw out the words business case and ROI as buzzwords. But very few people take the time to truly understand what those things actually mean to the business. What does a business case look like in your line of business? What is a healthy ROI to justify change? There is no silver bullet, but I’m interested in other people’s experience.

The purpose of a business case is to capture the reason behind why something should be done. Are we trying to transform the business, grow the business or run (maintain) the business? A business case should demonstrate value for the intended audience; after all there should be some business benefit. Does the business case increase revenue or decrease cost? What does value look like to your business?

Business cases often lack demonstrating strategic importance and are often built on questionable or incomplete ROI data. When justifying product requirements, it becomes even more difficult when the business benefits initially estimated from this data often dissipates through a product’s lifecycle. This can happen for a few reasons; it can be very difficult to make that one to one correlation to trace the impact of the requirement on the business benefit (revenue or cost savings). Second, the customer whom we received the requirements from can not make objective requirement prioritization decisions; this could cause a mis-prioritization of requirements leading to value leakage. Another reason could be due to the lack of a consistent approach for making decisions for finding the right or best solution for the requirement, this results in high lifecycle costs and diminishing ROI.

Many resource allocation decisions to develop products are typically tied to formal planning cycles aligned with strategic initiatives. That is why it is important to communicate the business case and the requirements in a language similar to the business and in a context that aligns with the strategic importance of the business. Making the right decisions depends on clear, objective, and consistently applied value language (or metrics). The value of the requirements may lie in their reflection of the strategic goals of the company and the resulting benefits that accrue to the company, like revenue, competitive advantage, market share, etc.

It is important to develop the link between a requirement and the business benefit. It enables product teams to prioritize business requests and present the business with time, cost and business benefit trade-offs. Requirements should go through an analysis that starts with the strategy. Then see how that strategy is broken down into particular business objectives. Break apart the business objectives into drivers of business value. Next apply a methodology that quantifies the impact of the requirement against these objectives and prioritize them accordingly. Then evaluate the lifecycle costs of the requirement and choose the solution that best satisfies the requirement. Keep in mind these steps or other steps you take should be conducted in a language similar to the intended audience.

When employing an agile methodology it is important to measure those key activities that deliver value and promote the right behavior. An Agile methodology can be measured with key measurement types such as productivity, quality, timeliness and utilization. As long as the measures demonstrate why and how an Agile method can affect the projects success and business value. 

Do not fall into traditional metrics that promote the wrong behavior or do not align with the project. For example, lines of code per developer week or per iteration or function points developed. This type of measure could promote code bloat as visibility is shed on generating lots of code or generating a lot of effort. Plus the more effort or lines of code in the product, the more there is to maintain. What is really needed is a measure to determine if the functionality was completed. A measure such as features completed versus features remaining. This measure will help determine how much business value was delivered to the customer, if the feature is not complete then there was no value delivered to the customer. The measures should drive the right behavior.

I recently had a conversation with an ex-colleague that now runs a project management organization. We discussed the challenges of measuring an agile methodology such as scrum. This organization just implemented scrum about a year ago. The organization had no baseline to compare against their scrum process. So it was difficult for the organization to determine exactly how much value their scrum process added compared to their old development process. This was a management decision not to spend the time or resources to baseline and normalize their old development process to compare to the new one.  

Instead the resources were spent on measuring their new scrum process. The organization measured everything they could. At the end of the day they were left looking at a bunch of numbers. Most of their metrics were still traditional metrics promoting the wrong behavior. They did not focus on what was important. Six months later the organization conducted the same exercise but focusing on what was important. What was important to this particular team was velocity. In scrum that is, the number of story points per sprint. This was important because the owner of the project needs this information to make release related decisions.

Measure what’s important and delivers value.

Customers define quality. Creating quality software means delivering a product that not only meets customers needs but also their expectations of how it should work. When is the last time any of us read a requirement document that outlined the customer’s perception of quality? I’m sure quality is omitted from a requirements document because it is assumed. Maybe quality is omitted because we are afraid to ask our customers to define quality for us. After all, we position ourselves with our customers as people who have all the solutions to all of their problems. We know everything, so we know all about quality. Right? Maybe we are afraid to ask about quality because we can not truly deliver quality. To be fair, the question probably does not get asked as much as it should because the customer’s definition of quality is always changing.

To meet this moving target we need to be more agile. Many organizations spend a significant amount of time up front gathering requirements. Prior to assigning development resources, the requirements are defined in a requirement document and all development decisions are based off that document. What if the customer’s requirement changes? There is a good chance the customers business landscape will change affecting the requirement. How would development know of this change from a static document that has been defined and approved 4 months ago? There is a good chance the requirement will be developed without instruction, a story or some context of how the customer will use the functionality to meet their changing business needs. How do organizations deal with this misalignment between the customers, their customers business and their own development lifecycle?

Many development organizations have addressed this type of problem by migrating from their traditional code and fix or waterfall methodology to a flexible agile development methodology such as XP, Scrum, EVO, ASD, etc. Agile methodologies promote frequent adaptation through iterative steps called iterations. Each iteration lasts a short period, is worked on by an entire team through a development cycle. The benefits of agile methodologies provide organizations the ability to adapt quickly to customer’s needs and expectations. Many organizations employ a more hybrid agile approach to fit their organization.

Organization’s that employ a type of agile methodology improve their chances at meeting customer expectations and delivering quality in the eyes of the customer versus their code and fix or waterfall counterparts. Even if your organization does not employ an agile methodology find a way to narrow that gap between requirement gathering and user feedback to ensure the product is meeting the customers needs and their expectations. The next topic will discuss measuring an agile program.

Defining and collecting metrics should be a disciplined part of every project or deliverable as a feedback and evaluation mechanism. When unsure what to collect, organizations often collect everything and wind up with, well in many cases not much, just a bunch of numbers. A method that provides focus in determining what to collect is the Goal-Question-Metric (GQM) method. This top-down, goal-driven method was developed by Dr. Victor Basili during the 1980’s in conjunction with his work at NASA. GQM provides a framework for developing and maintaining a meaningful metrics program that supports metric alignment with organizational goals. GQM can be applied to all life-cycle products, processes, and resources.

GQM Basics –

• Develop corporate, organizational or project goals.
• Generate questions that define those goals in a quantifiable manner
• Define the metrics needed to answer those questions in conformance to the goals.

With each goal, question and metric a mechanism is required for data collection and validation. Analysis of the data is required to provide timely feedback for corrective actions. Analysis of the program itself is required to assess conformance to the goals and improvements.

Some best practices for implementing GQM across all levels (strategic, tactical and operational) include -

• Implement in a phased approach to ensure quality and focus.
• Get the right people involved at all levels, cross functionally.
• Secure management commitment.
• Set and communicate measurement goals.
• Do not reverse engineer goals based on available data.
• Plan, document and establish the infrastructure for the metrics program.
• Stay focused on goals when analyzing data.
• Ensure each metric has a goal, owner, target & corrective action plan.
• Metrics need to be ones that drive the right behavior.
• GQM is a tool, not the end goal.

GQM has long been in the industry. It is a large yet critical topic; this approach should be the cornerstone of any program.

With economies struggling, industries transforming, our customer bases shrinking and the federal government bailing out what seems to be everyone but the people, there is no more critical time for good data than now. This blog is focused on helping clients jump start their core business to make better decisions for their organization.  

As another year begins I still hear the same questions and see many of the same behaviors. All too often we start addressing a problem or a symptom of a problem with a different understanding of the situation. Our view points differ by terminology, the definitions behind the terminology, our background on the situation or the underlying assumptions. Many times we start addressing an issue without being on the same page or having the same baseline understanding of the situation.

Where do we begin? Many organizations are busy tightening their bottom line as many of their customers are spending less because of the economy. Many organization’s are faced with the challenge of what products to keep, which to outsource, which to discontinue, which people to keep, which people should go where, and what processes can become more efficient to save money. It has never been more important for organizations to do this type of analysis than now. Although this should be an ongoing exercise, it is a new one for many organizations as there is a dire need for good data to make these critical business decisions.  Where do we start?

Start small. Whether the organization is trying to gather a metric to answer a business question, trying to implement a metrics framework or working to measure a deliverable to show value, it is important to start small. A limited scope in the beginning will keep focus and keep the program in an achievable state. Avoid the temptation to expand until after the initial phase has been established. In many instances, it is more productive to finish 1 task in 5 than it is to do 20% of each of the 5 tasks.

Avoid the temptation to expand the metric, framework or deliverable if your data can not easily be obtained. What are you going to do if the data is not available? A decision to a business problem still needs to be made. Are you going to throw out your framework? Add to the deliverables with the data that is available? Pound qualitative data into a quantitative hole? No, focus on what you are trying to achieve. Focus on what has been defined to answer these business questions related to value as it relates to your function. Is the framework aligned to the organization’s goals? Does the metric answer the question on whether or not a goal is being met or the deliverable has value. It must! Why do it if it isn’t? Many times individuals (including managers) perform data collection activities or define metrics without realizing or knowing if their activities align to a goal or provide actual value to their core business.

There will be times when you are asked to deliver data that is not available or it is a “nice to have” data point. If this happens, I would recommend communicating to the stakeholders that the data does not appear to be available and the effort should be focused on implementing a collection method to get the required data. Do not deliver data that has been poorly defined or collected or does not answer the question. This type of data will provide little to no value and only expose you to questions and credibility issues.

Stay focused and do not become side tracked in the “nice to haves”. For those instances, set the expectations that the “nice to have” data or activities need to go through the stakeholders to justify the value to the business.

Start small and stay focused.