Tag: Technical Project Management

5 Killer Questions Types For Digital Transformation

Written by Elizabeth Larson on March 26, 2019. Posted in Articles. 1 Comment on 5 Killer Questions Types For Digital Transformation

A recent article concludes that for an organization to get the desired results from their digital initiatives,

such as data analytics, predictive analytics, machine learning, AI, etc., data scientists have to ask the right questions.[i] The article was written as a guide for data scientists to help them ask questions to get at the business decisions needed to be made when developing predictive models for these applications.

However, the article’s questions are stated in a way that might cause even the most informed business stakeholders to scratch their heads. If most decision-makers can’t answer them knowledgably, what can the organization do? Get BAs involved, of course! Having a BA participate in the question and answer sessions can alleviate a great deal of misunderstanding and help ensure success with digital projects.

This article imagines that for each of the 5 question types, there is a three-way conversation with a data scientist, a business decision-maker, and a BA. The questions the data scientist asks are from the article, which the BA rephrases to be more easily answered.

Type 1 – Alignment with the organization’s goals and strategic direction

Data scientist to business stakeholder – First things first. What exactly do you want to find out with this digital effort?

Business stakeholder to data scientist – I’m trying to predict sales of a new product we’re thinking of launching.

Business analyst to business stakeholder:

I’m sure this project can help with that effort. But before we talk about specifics of the types of information you’re looking for, what is the business need for this effort? That is, what problems are you trying to solve? Let’s make sure this initiative, which is not going to be an easy undertaking, will address your need. Perhaps there is a quicker, less costly way to achieve your goals. And I have some related questions that will give us more context:

How does this effort align with the strategic direction of the organization?
What are does the organization do well that will help ensure the project’s success and minimize risks?
How will this project help overcome some of the things we don’t do so well?
What opportunities are out there and how can the organization take advantage of them?
What should we be worried about? How are competitors, for example, doing with their digital initiatives?

Type 2 – Scope of input needed to create and train models

Data scientist to business stakeholder – Where will your data come from?

Business stakeholder to data scientist – I’m sorry, I don’t know the names of the specific databases. I thought I was here to make business decisions, not answer questions best answered by the IT folks.

Business analyst to business stakeholder – At this point we don’t need to know the names of the specific databases. What we mean by where the information will come from are things like:

Which business areas will be involved in this project?
Which stakeholders will have input into the decisions affecting the creation of the models?
Given that this effort will affect divisions in different parts of the world, who will establish the business rules?
What types of information will come from other sources, like social media and Google analytics?

Type 3 – Data presentation

Data scientist to business stakeholder – What data visualizations do you want us to choose?

Business stakeholder to data scientist – I’m sorry, I don’t understand what you mean. Do you mean like how I want to see the data? If so, I don’t know. What are the possibilities?

Business analyst to business stakeholder – There are a lot of tools that will take the data and interpret the results for you. They help you make sense of the tons of data you’ll be presented with. They can help you analyze data, point out anomalies, and send out alerts that you specify. They can be in the form of charts, dashboards, or whatever, but keep in mind that if they are hard to read, they will be meaningless to you. I can show you some examples and the pros and cons of such things as animation and use of images, but first let’s talk about the information itself.

What results are you hoping to get?
What type of predictions about your customers would be helpful? Your products?
What types of trends would be helpful to you in making business decisions?
What types of exceptions do you want to be alerted about?
What information do you want that’s actionable vs. historical?

Type 4 – Statistical analysis leading to the desired outcomes

Data scientist to business stakeholder – Which statistical analysis techniques do you want to apply?

Business stakeholder to data scientist – Well, statistics is not my strong suit. What are my choices?

Data scientist to business stakeholder – Regression, predictive, prescriptive, and cohort, and there are others, like descriptive, cluster.

Business stakeholder to data scientist – blank stare

Business analyst to business stakeholder – Maybe I can help here. These types of statistical analyses have a number of similarities. They include use of historical data, algorithms, models to train the machines, and business rules. Not to oversimplify and at a very high level, all predictive models make use of historical data and algorithms to predict future outcomes.

Here are questions based on examples of different outcomes using different statistical analysis:

What groups of customers do you want to target? Cluster analysis classifies data into different groups and can help you target certain customer groups.
What types of trends do you want to track? Cohort analysis allows you to compare how groups of customers behave over time.
What kinds of recommendations might you want as a result of the analysis? Prescriptive analysis not only predicts future outcomes, but it will “prescribe” or recommend the best course of action.

So to answer the question we need to understand what you’re trying to accomplish. We’ll let her (nodding to the data scientist) figure out the most appropriate analysis method and tool.

Type 5 – Creating a data-driven culture

Data scientist to business stakeholder – How can you create a data-driven culture?

Business stakeholder to data scientist – We already have a data-driven culture. Everyone in this organization understands how important data is to our ability to survive as an organization.

Business analyst to business stakeholder – This might be more complex than it first appears. In order to use historical data, which we need to do regardless of the chosen algorithms, it needs to be cleansed. Cleansing is needed to make the data predictive, and cleansing data takes lots of time and money. And it’s the last thing anyone wants to do. So I have some questions for you:

What’s the organizational commitment to cleansing dirty data?
Who will decide how clean the data needs to be? How clean is clean enough?
Who will decide who owns the data when the same data exists in multiple databases? In order to get the outcomes we want, there needs to be one single source. If the same data exists in multiple databases, someone needs to be its sole owner.

In sum, we’ve provided questions within 5 question types. However, to be effective, we BAs need to learn as much as we can about the digital world—about the world of digital transformation and what it means for the organization. We need to immerse ourselves in research and journal articles and think of how to make sense of it for our organizations. We need to think of digital projects from both the data scientist and business perspectives. And we can do that. After all, we’re BAs and that’s what we do best.

[i] Your Data Won’t Speak Unless You Ask It The Right Data Analysis Questions, By Sandra Durcevic in Data Analysis, Jan 8th 2019, https://www.datapine.com/blog/data-analysis-questions/

Secrets of the Cat Herder – Part I

Written by Darryl Ricker on August 24, 2018. Posted in Articles.

How to be in control of the Development Team that your project depends upon

“Control your own destiny or someone else will.”
– Jack Welch

If you’ve spent any time as a Product Manager, Business Analyst or Product Owner, I’m certain that you have experienced frustration dealing with an Engineering team. I am here from “the other side” to help. I have spent the majority of my career on the technical side of software development, but also a significant portion in “business” roles such as Product Management. The purpose of this article is to let you in on the secrets I have learned from being on both sides; these secrets will help you assert control over your projects.

First, I should say that we¹ don’t really mean to be frustrating – as a rule, we are trying to the best of our abilities to achieve what we believe to be the objective of our department. The problem is that we often have a different objective than you do. What is the Engineering team’s objective? Like the blind men and the elephant, you will almost certainly get different views on the topic from each Engineer.

As a business person, you might surmise that it is something like “spend a lot of time using cool new technologies to create a small amount of business functionality while staying gleefully unaware of business pressures”. Trust me, that’s not what any of us would write down.

Here’s the good news: the actual objective of Engineering is the exact same as what I assume yours to be: to efficiently (i.e., rapidly and cost-effectively) deliver valuable business functionality for Customers. How can I be so certain?

The essence of my analysis is based on the fact that the Engineering team must share the same objective as the overall company, which for most for-profit companies is to maximize profitability (although if the company is publicly-traded, it is more accurate to say “increase shareholder value”). To skip a few steps in the reasoning and cut to the chase, this is normally done by maximizing the valuable functionality delivered to the Customer; to restate for effect:

The primary purpose of Engineering is to efficiently create valuable functionality for Customers².

Although they both might assume otherwise, you can see that the business people and the technical people share the same objective. So what’s the problem?³ The chief problem is that the Engineering team doesn’t know this yet.

Notice that the objective stated above doesn’t say anything about architecture, frameworks, languages, coding standards, testing approaches, etc. These are the things that Engineers love to focus their time on and things that the outside world assumes to be their primary objective. It’s not to say that these things are not important, but they are only important in so much as they help achieve the overall (and really, only) objective which is to provide value. A corollary of the above objective is the following:

The only Engineering activities that are worthwhile are those that lead to delivering value to the Customer.

I often talk about something I call the “Customer Membrane” – it’s the surface area where we exchange things with the Customer, such as the software we deliver, designs, requirements, feedback and usually some form of payment for the value that it is delivered. The Customer Membrane looks something like:

I propose that if something isn’t visible in the exchange at the Customer Membrane, then that “thing” is not particularly important. For example, if the team has decided to use an obscure programming language in the back-end of their cloud-based solution, this doesn’t matter to the Customer. So let me repeat this in bold print for emphasis:

The most important Engineering work is that which is obvious across the Customer Membrane.

You can use this fact to help keep the project team focused on those tasks that make a difference and not those that are really interesting to the Engineers, but not valuable to your Customer.

So how do you help the Engineers figure this out? I am a big believer that revolutions start in one of two ways – from the top down or from the bottom up. I suggest starting with the former since people at the top generally have the authority to start a revolution.⁴ Start by working with Engineering leadership to convey the above ideas (I will provide more supporting materials in the next article). Engineers are very logical and my experience is that when these ideas are explained clearly, it makes sense to them. At first, it goes against their natural instincts, but with repetition, the passage of time, some successes and the realization that they can still do great and interesting Engineering work, they will come around. I promise.

One of the most common objections to the message is that it prevents Engineering from doing “their thing”. Because they hear words like “value” and “functionality” and “Customers” and not a single technical term, they assume that there is no place for technology. One key thing that I’m not saying in this definition is this: “Engineering can no longer use new, interesting technologies and do challenging, innovative work.” Choosing to make the delivery of business functionality the primary focus does not prevent innovation and the application of cool technologies. However, it is very different than focusing first on picking shiny technologies and worrying later how they might be used to deliver on the business needs.⁵

Until Engineering leadership buys into the fact that their only objective is to efficiently deliver valuable functionality, it will be difficult for you to progress. Therefore, I encourage you to be persistent in delivering this message. If you can’t get support from the leadership, then go to Plan B, which is the grassroots Revolution. Try instead delivering the message only to the Engineering team working directly on your project. It’s a smaller group to sell the idea to and, if successful, they might be the wedge that helps you to convince the larger group. Either way, you need to do your best to get this message to percolating in the Engineering side of the company.

I’ll continue this discussion in my next article here, but in the meantime, I invite you to take a tour through my blog site at de-engineering – it covers the above concepts in more detail.

Footnotes
1 I normally self-identify as a techie.
2 Keeping in mind that the “Customer” can be an internal one.
3 Because there definitely is a problem!
4 Although you can’t authorize your way to a revolution, despite frequent attempts.
5 I suspect that many of you can identify with this type of environment. What you don’t realize as business people is that new technology is like catnip to us Engineers. When you don’t control the infusion of new technology, you create one of those crazy cat playgrounds where disorder rules supreme. The phrase “herding cats” did not get invented by accident (by the way, the original video that spawned the phrase can be seen here).

The One-Eyed Man in the Land of the Blind

Written by Colin Hammond on July 19, 2018. Posted in Articles.

Almost everybody these days sizes software story points. But what is a story point? To every agile team, it means something different.

For a self-governing agile team, the story point is principally about effort and time spent than a measurement of delivered functionality. Tasks that don’t deliver functionality are also measured in SPs.

The job of a software Project Manager is far more than just representing a burn-down chart; he needs something more user-oriented, and more universal. Appropriate metrics are essential for a well-managed project. SPs are inadequate for PMs except for the estimation and measurement within the context of a single agile team.

As it happens, there is a good technique for software project estimation and measurement. Not many people are aware of it, nor how to use it effectively. BAs have a great opportunity to introduce this and raise the certainty of software projects.

Before diving in on the answer, let us take another look at the wider context.

Budgets for software changes are typically assigned at the project level, not for a stream of work (which is how Agile teams are set up). Agile teams’ estimates are based on story points, which can vary wildly from team to team and organization to organization.
Senior IT management expect PMs to give reliable delivery dates, firm cost estimates based on expected functionality – all up front. Story points are not a suitable metric for development contracts.
Agile practices are very effective at producing software – the customer usually gets what they want, in due course. However, Agile teams struggle with whole project estimation.
Agile teams self-manage using (arbitrary) story points and a finite capacity to deliver work each sprint. However, senior IT management cannot budget, measure or report based on story points as a business metric.

Part way through my career I learned about a technique from the 1970’s called Function Point Analysis (FPA). I was shown how, when used thoughtfully, this technique can bring incredible predictability to software projects. FPA is the process of counting Function Points (FP), a measure of software size from the user’s perspective. FP’s are the only ISO standard approved measurement of software and are even suitable for development contracts.

So why have so few people heard of FP’s? There are likely to be several reasons, but mostly, they are considered old-fashioned, and they are hard to count. Counting function points has always been a manual process. Around 20 years after the initial methodology was invented, an updated revision was published that addresses many of the criticisms of the original method. Cosmic Functional Sizing (cosmic-sizing.org) is the latest incarnation of this ISO standard. Cosmic, brings the technique up to date for modern software architectures and is a principle based method.

Function points can be counted even before the software is written. They are far more appropriate than story points or lines of code because they focus on the measurement of functionality from a user’s perspective.

There is substantial data available on the statistics of past projects measured using function points, specifically the writings of Capers Jones and data available from ISBSG.

Function Points are about size measurement, but they can also be used for estimating and managing other aspects of your software project:

Size: FPs to be developed or changed as part of the project.
Scope change: as above.
Quality: defect potentials per FP and defects found per FP are two examples.
Schedule estimates: number of months needed to delivery a given number of FPs,
Schedule adherence: adherence to an expected delivery rate of FPs per month.
Resources allocation: Staffing and costs needed to deliver an amount of FPs
Earned value delivered: FPs are a direct indication of useful user functionality.
Vendor estimate validation: compare proposals against typical industry costs per FP

For the last ten years have used function points on every software project. They have given me great insight, very quickly. Most of these projects have involved Agile software delivery teams and I have measured the FP’s alongside the story points. This works just fine. Story points are the primary metric for output and productivity within a scrum team and FP count is my primary metric at a vendor, project and even portfolio level.

Once I discovered how effective and valuable FP’s are to me as a PM, I was surprised that I had not come across them before. It seems that so few people are aware of, or appreciate the value of them. There are perhaps a few reasons for this:

FPs are considered old-fashioned and irrelevant to modern techniques. This objection is no longer valid having been addressed by the latest generation of Functional Sizing Methods, Cosmic-sizing.org
Functional Sizing is considered to be hard to learn. Yes, I spent many months learning to become competent and certified in counting IFPUG FPs. The Cosmic method is considerably easier to learn. And now with the automated counting tools doing the heavy lifting, there is less need to spend time learning the methodology.
Cost, you have to pay to obtain the IFPUG manuals. The Cosmic method is a free open-source project.
Counting function points takes time and businesses have neither the time nor inclination to allocate to the sizing activity. A false economy of course. Nevertheless, there are tools now on the market that count FPs for you, from pre-existing code, see CastSoftware, or from user stories / requirements, see ScopeMaster.
There is little understanding of the potential co-existence of FP’s alongside story points. This is what I have practiced for the last ten years it works just fine.
Development vendors generally avoid quoting in FP’s. I believe that this may be because it would equip the purchaser with a metric to negotiate a lower price.

I highly recommend that you take some time to look into the free project cosmic-sizing.org. Once you have the ability to count and use function points, you will feel like the one-eyed man in the land of the blind and eventually colleagues will turn to you for guidance.