Tag: Technical Project Management

Why Agile isn’t Enough Part 2: Lean Startup Build Phase and BA Techniques that Enhance it

Written by Richard Larson on July 8, 2019. Posted in Articles. 3 Comments on Why Agile isn’t Enough Part 2: Lean Startup Build Phase and BA Techniques that Enhance it

In part 1 of this article, we covered an overview of Lean Startups and its Build-Measure-Learn (B-M-L) methodology.

To recap, in the B-M-L cycle we build a product increment, measure how it is adopted and used, and learn from the measures about what worked and didn’t and use it for the next cycle.
In this part we’ll examine the Build part of the cycle in more depth and see which Business Analysis techniques are most helpful to propel the Lean Startup to providing innovation and value. Part 3 will cover the remaining two parts, Measure and Learn.

BUILD

To review, the Build-Measure-Learn methodology within Lean Startup is the central engine driving the process. Lean Startups rely on repetitive cycles of B-M-L to produce various product increments as recapped in Figure 1. An important milestone while building a product is to reach a Minimum Viable Product or MVP such as in “P2” below.

MVP

The concept of a Minimum Viable Product was popularized by Eric Ries in The Lean Startup1 and has been genericized quite a bit in our industry. In Lean Startup an MVP is the product produced with the minimum effort and the quickest path or paths through the B-M-L loop. Product P2 in Figure 1 shows an MVP produced after two times through the loop.

Figure 1: Lean Startup Framework

More than a prototype or proof of concept, the goal of an MVP is to test fundamental business hypotheses about a product. For example, the hypothesis of whether customers would pay to have DVDs shipped to them and return them by mail was the basis of Netflix.

Another way to think of an MVP is “a first attempt at building a solution to a problem worth solving.” The learning starts with testing the fundamental hypothesis and continues with each new feature added. We’ll return to learning in part 3.

Take the video communication app called Marco Polo. This app allows family and friends to communicate by directly sending videos right from the app. That’s basically all the app does, but I can tell you our family is totally addicted to it! It is valuable to us since we live in cities across the US and can hear and see what family members are doing. It’s incredibly valuable to us since our kids and grandkids keep us updated much more often with it than by phone or email.

Marco Polo is now a bit beyond an MVP as of this writing, but not much. The initial MVP just let users record and play videos and was enough for their startup to learn from. They added the ability to Fast Forward and Rewind based on user feedback. They also added a few other features, but it is still fairly basic as of this writing. Without a Lean Startup mentality, though, adding additional potential features would have delayed their launch and may not be widely used.

MVP: “A first attempt at building a solution to a problem worth solving.” Eric Ries

Leap of Faith

All startups are based on assumptions and get started as a “leap of faith.” It’s the basic hypothesis of a new product or company. There is a paradox here, though: we aim to ultimately build things for the “masses”(see Figure 2) but need to start with the early adopters or our product likely won’t get off the ground.

Figure 2: Product Adoption Over Time

It’s important to know and note the assumptions that form the “leap of faith.” Business Analysis skills can help by ferreting out and documenting those assumptions. As we do that, it’s important to avoid false analogies that obscure the “true leap of faith.” Eric Ries in The Lean Startup suggests we shun borrowed analogies like “this worked for Apple so it will work for us.”

Speaking of Apple, their Apple Watch was a leap of faith whether people were willing to read texts or listen to music on their watches, which many did want and still do.

Build – 13 techniques

Figure 3 lists the BA techniques for the Build phase. Looking through the list, which techniques have you found to be the most helpful in developing new products? If I was on a desert island and could only use 5 techniques, I’d have to say Benchmarking, Brainstorming, Lean Canvas, Observation, and Prototyping would be my choices. The details and applications of the techniques are beyond the scope of this article but are intended to be a reference.

Figure 3: Techniques Useful in the Build Stage

The Business Model Canvas is becoming more and more popular and for good reason. But it is meant more for established business and doesn’t help as much as a newer technique called the “Lean Canvas.” The Lean Canvas tool helps focus on customers and their solutions based on need. See Figure 4 for an example. Like the Business Model Canvas the Lean Canvas has nine categories to help spur thinking and help create a product of value.

I particularly like the first two categories, “Problem” and “Solution,” since they focus on two of the most critical aspects of delivering a valuable solution. I also like including “Key Metrics” in the middle and we’ll discuss metrics in Part 3. The upper right-hand section labeled “Customer Segments” is also a key factor since it focuses on the customer and possible segments or “cohorts” of users.

Figure 4: Lean Canvas Example

Customer Segments is also valuable since we have found as entrepreneurs it is critical to first find customers in need and then build or deliver solutions that will appeal to them. It is much riskier and potentially wasteful to build products and then find customers we think will need them. Take the example of Teforia, who built a “tea-infusion system” that sold for up to $1,300 per machine. As it turned out, people weren’t willing to pay that much for tea so the product was a failure (and the startup folded).

Summary

In summary, the Build portion of the Lean Startup methodology leads off the cycle. It relies on vision and ideas for solving a problem at first. It then uses learning from product measures to adjust the product with new or changed features in future cycles. The final part of this article will explore the latter two portions, Measure and Learn, in more detail.

Lessons Learned from Bhutan and Nepal: Part 2 – Process Thoughts about Digital Transformation

Written by Elizabeth Larson on June 6, 2019. Posted in Articles. 1 Comment on Lessons Learned from Bhutan and Nepal: Part 2 – Process Thoughts about Digital Transformation

In this age of digital transformations and the digital BA, data matters.

Without data there would be no big data, no data mining, no machine learning or predictive analytics. No AI. Nothing digital to transform. So yes, we have to focus on data. But what about poor process, once the king of projects, now often relegated to an afterthought? We commonly use to data improve processes. With better data, many cumbersome processes can be automated and improved beyond recognition. But process in and of itself still matters.

The importance of good processes was highlighted for us on a recent trip to Nepal and Bhutan. Getting into Nepal was beyond difficult and frustrating. To enter Nepal from the US you need a visa. Many countries require visas, and the processes to obtain those visas vary in the degree of difficulty. But Nepal was unique. We applied for the visa online, so they had our data. But there was no process for doing anything with that data. When we arrived, the fact that we had applied was irrelevant. We waited for nearly 2 hours in the same lines as everyone else. Once we got in, we really enjoyed our visit to Nepal. But the entry process was pretty awful. Bhutan, on the other hand, was a breeze. So here are 5 process lessons learned from this trip that apply universally.

Lesson #1: Before we can improve a process, we need to understand how it works today.

As much as we’d like to jump in and make a process better, we need to understand the current way things are done. It sure would be tempting to send some business analysts to “fix” Nepal’s visa problem, but there’s way too much we don’t know about why things are done the way they are. We need to understand how process works, as well as workarounds, exceptions, and little tidbits that make the process better for the people doing the process, if not for the customers and the entire organization. We also need to be aware of the personal, practical, and political reasons things are done as they are. We suspect the immigration officers in Nepal were as tired of the long lines as we were. We suspect that they would have loved to double the number of agents and to have better automation. We have no idea of the constraints and pressures they felt, and without that understanding, the process cannot be improved.

Lesson #2: A process map helps.

The second part of the trip was Bhutan, and one of the Bhutan activities was a hike to a monastery called the Tiger’s Nest. We posted a photo in Part 1 of this article. It sits perched on a ledge in the middle of a mountain and requires a 3,000 ft fairly vertical climb to 10,000 ft. Given the altitude and the age of everyone in our group (over 50), it caused a certain amount of anxiety, even though we were all physically fit. Some of us watched YouTube videos of the hike, but those hikers were all much younger than everyone in our group.

The night before the hike, our Bhutanese guide called a meeting to prep us for the next day’s hike. To our delight, he brought out a flip chart and drew a graphical depiction of our hike—a kind of process map! Palee explained the different levels, where we could get tea, where we could take the most scenic photos, where there was a dirt path and where there were steps, and importantly, where the few restrooms were located. We still had some trepidation but felt much better prepared.

Lesson #3: Process maps are usually incomplete.

But even the best of process maps doesn’t prepare us for all the exceptions. There are often unexpected forks in the path and choices that have to be made. It would be great to learn a process by reading existing documentation, but it may not be up-to-date. It probably won’t have all the exception paths. It certainly won’t have the workarounds that experienced staff know and love. If we rely on documentation alone, we might go astray. As helpful as our guide’s process map was, it did not prepare us for how we would react to altitude, for the numerous forks in the path, for how to share the path with horses, nor the hordes of hikers on the same hike.

Lesson #4: A guide makes a process easier.

The first decision point was whether to hike or to ride a horse to the first level. Since one person chose the horse, our guide was unavailable to steer the rest of us through the other exception paths. As we wrote in Part 1, three of us in our group of eight were ahead of the others when we came to our first fork in the road. Which way to go? Go with the flow of course and the flow of hikers in front of us chose the right-hand path. It turns out it was a big mistake. It was a terribly steep and difficult path. We were about a quarter of the way up when one of the hikers shouted down to a friend—“take the right-hand path. It’s shorter. Much steeper, but shorter.” The path was so steep that we didn’t want to turn around, hike back down, and take the other path. We came across many other forks in the road, but our guide was always there to show us the way, which made our hike far easier.

Lesson #5: The shortest path is not necessarily the fastest.

When we finally joined the other path, the rest of our group was actually ahead of us. They had taken the longer, less difficult path and they were farther along. And were far less out of breath. There are times when shortcuts make sense. When we blindly follow processes just because “we have always done it this way,” we take a giant step towards bureaucracy. However, our shortcuts need to be well-conceived, and we need to understand the consequences of taking a shorter, less-known path. If that shortcut is tested and well-understood, we need to recommend that it replace the existing process.

By the way, everyone in our group made it to the top—and it took us about two hours less than our guide originally estimated. We have our wonderful guide Palee to thank–he was a great PM, BA, knowledgeable SME, and overall great guy.

Written by: Richard Larson and Elizabeth Larson

Part 1: https://www.projecttimes.com/articles/lessons-learned-from-bhutan-and-nepal-part-1-product-thoughts.html

A “Novel” Way of Gathering Requirements

Written by Kathleen Booker on May 9, 2019. Posted in Articles.

You look at the clock. The hands tick toward midnight.

You know that you should not be up this late because you have a meeting with your project team first thing in the morning. But you simply cannot put the book down. The latest novel by your favorite author is one of the best you have ever read, and you are so deep inside the protagonist’s head that you lost all track of time. It is the turning point for the main character, so you sigh deeply and concede that you have to read just one more chapter.

As you finally put the book down and rest your head on your pillow, you think about how well the author lays out the characters and plot. Being an avid reader, you recognize that this particular novel is written in third person omniscient point of view. The thoughts, desires, needs, and motivations of the characters in the book are all there for you to examine and absorb. With this point of view, it is easy to relate information about and between each character in the story. When any novel is weaved in such a way that the reader gets lost in the pages, when he or she understands each character’s plans and goals, and when there is insight into potential outcomes, the writer has done his or her job well.

As project managers, our objective is not to present a best-selling novel to our stakeholders, but we should be creating well thought-out and complete (as possible) requirements documentation as if we are writing from the third person point of view. It is up to us to make sure that the requirements are in tune with each of the stakeholders’ desires and needs and, of course, what the project goals demand. To accomplish this, we must get inside their heads to make sure we understand the thought process behind the requirements.

In the PMBOK® Guide a requirement is defined as “a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.” It is important to note that just like many things in business (and in life) one person’s definition of satisfying a need may be a lot different from another person’s.

Achieving an as-perfect-as-possible requirements document takes time and effort, and like writing a novel, this part of project management, in my opinion, can be an art. Just as a writer might have several drafts of his book before it is ready for publication, so too will the PM have a requirements document that may go through several iterations before the final version will be circulated to the team (and even final versions can be subject to change). Each requirement needs to be dissected and assessed to determine if any errors in assumptions or conflicts between individual stakeholder input exist. Key in this requirements gathering process is that the project manager has a good understanding of what each one means. You do not need to be a subject matter expert, but you do need to have a high-level understanding of the requirements. Make sure you ask your stakeholder enough questions if you do not grasp the purpose of the requirement so that you can document it accurately. In other words, get inside the stakeholder’s head to extract exactly what he means, not just what he says. Make sure it aligns with the project charter and scope, and insure there is a clear vision of how it fits in the plan. Everyone, not only the stakeholder, should be able to understand the purpose of each requirement.

If conflicts arise between what one stakeholder requires and what another stakeholder desires, a good course of action might be to meet with both of them to discuss the nuances and come to a common ground. Resolution may not come at once, but the conflict must be addressed as soon as possible. The solution may become apparent while creating the cost or risk management plans; or perhaps it is a time or quality concern that will dictate how to proceed. It is possible that a conflict will not be fully resolved until the proof of concept phase. It is in everyone’s best interest to try to resolve issues while insuring the best possible outcome. But keep in mind, that while stakeholder “A’s” requirement may have initially been deemed more in line with the project goals, since requirements management is iterative, it could happen that Stakeholder “B’s” requirement may turn out to be better suited to the project.

Ultimately, it is the PM’s job to make sure that all documented requirements are clear, concise, and achievable. Each stakeholder and project team member should be able to read the document and envision how each requirement contributes to the project. It should be apparent that the PM has put in the time and effort necessary to develop the requirements story that will engage the team and propel the project to a successful outcome.

The BA Toolkit for Innovation

Written by Steve Palmer on April 23, 2019. Posted in Articles.

Folks, it is time to come to terms with one simple fact. In business, disruptions happen. They aren’t new.

You can make an argument that the first disruption happened 66 million years ago when the business of the Dinosaurs was disrupted by the meteor. And, since the start of the Technological Revolution, disruptions are a trend that is picking up.
Today, because of increases in technology, available capital and global competition, they are prevalent than ever. Need proof? Look at the graph below brought to you curtesy of Innosight. Clearly, the trendlines on the average corporate lifespan are trending down.

Source: Innosight

Today, 93% of Executives know their industry will be disrupted within the next 5 years according to research performed by Accenture. Yet oddly enough, only 20% feel like they are ready for it. But, just as your corporate executives begin to belt out the lyrics the Mariah Carey’s “Hero” at their favorite local late-night karaoke spot, the Business Gods have delivered to them the hero they needed.

That hero’s name? The Business Analyst!

Business Analyst – Hero for Hire

OK, so, business analyst is more of a role than a person. But however you slice it, it is indispensable in the modern business climate.
We have a saying at Ever Evolving. Never launch an initiative that you don’t know will succeed. The best way to end up on the short side of that corporate lifespan chart above, is to raise a big fuss over something that nobody cares about. And it happens all the time.

There was the Ford Edsel. Microsoft Vista. BlackBerry Storm. Apple Newton. Shall I continue?

Okay. Facebook Home. The Alliance of American Football. Microsoft ME. Windows Phone.

Man, Microsoft has trouble with their product launches.

Anyway, still continuing… Sony Betamax. “New” Coke. Google Plus. Qwikster. Blockbuster Digital.
Sometimes companies launch pet projects that never find a market. Sometimes they see a new threat enter the market space, and they hurry to meet the challenge by launching prematurely. Either way, they both end in disaster. Some companies recover. Others don’t. But they are all avoidable.

And that’s where the BA comes in. Through their use of metrics, indictors, balance scorecards, and all the tools that you already know and love, you can prevent that bad launch. Through the use of small-scale experiments, or what we call Profit Scalability Pilots (PSPs), and timely and appropriate metrics, the BA can gage market interest. Allowing the Titanic to swerve and avoid that iceberg. Or blowing up a model Hindenburg before inviting in the crowd.

Through those experiments, you can learn key insights – such as:

What users are really interested in my product?
What features are the most important to our userbase?
How much value is my product providing its intended audience?
How likely is this product to succeed?

How Can You Do It?

The key is to capture that information before you launch. Companies need to provide safe space for new ideas to fail internally. Internal product failures are learning experiences. They bring new insights into your markets and build new capabilities. External failures are embarrassing and cost people their jobs. That’s where the BA comes in. They steer the ship towards the former and away from the later.
You work with your product developers, your sales staff, your marketing gurus and project managers to determine what insights are needed. You work with your PMs to identify the targeted user groups and determine which profitability metrics need to be captured and tracked. You work with your marketing staff to gather and track metrics about how the messaging is received. You track develop tasks to identify whether the build out is proceeding according to plan.
And that’s where the small-scale experiments come in. Call them what you want – whether you like our idea and call them a PSP or if you subscribe to the Eric Ries’ method and call them a Minimal Viable Product – the goal is to get something small released soonest to learn about the market. Learn about the challenges. And then track the metrics over time using your Balanced Score Card. Leverage your indicators to predict the effort’s likelihood of success. And then presenting that information to your corporate leadership.

Want to Hear More?

This is a topic near and dear to my heart. Which is why you’ll be able to hear me speak on it at two upcoming Project World Business Analyst Summit events. The first one is in Washington, DC, where I’ll be presenting on April 30th at 1:15pm in the Salon C room. The title of my talk is Analyzing Innovation Across Business Lines. Tickets are on sale now for the event, and they can be purchased on the Project Summit Business Analyst World website by clicking the “Register Now” button.
If you can’t make DC, that’s OK. Because the real fun is happening the following month in Toronto. In Toronto I’ll be presenting the same talk (with maybe a few new jokes?) on May 27th from 2-3pm. I’ll be following that up the following day, May 28th, by presenting Innovation: The New Currency of Business which highlights why it is imperative for your organization to focus on new initiatives and product lines. And then I’ll be closing the week with a full-day workshop on May 30th. The workshop, titled Charting a Course Through the Innovation Minefield, will provide a deep-dive on the various stages within a corporate innovation pipeline. And it will highlight where in the process those PSPs come into play, where the metrics are tracked, when the indicators are brought up, and exactly where and how the BA provides their value. Tickets for Toronto are also on sale, and you can find them here. Again, just click on the “Register Now” button on the landing page.

The Purpose, Scope, and Value of a Six Sigma Project

Written by Jane Thomson on March 26, 2019. Posted in Articles.

Six Sigma is a collection of tools and techniques that are focused on eliminating defects in a product, process or a service.

It is a disciplined and data-driven approach. It was developed by Motorola based on the fundamentals of quality management. The six sigma process includes many activities like measurement, improvement, and validation. It emphasizes the relationship between the performance of the product and the corrections that are required during the manufacturing of the product.
Six Sigma projects are used to measure the cost of improving the processes that are producing substandard products or services. Whether in service or manufacturing industries, these projects quantify the effect of process changes on delays or rework. The aim of each Six Sigma project is to produce statistically significant enhancements in a particular process. These projects use suitable tools within the Six Sigma approach to producing financial benefit and improved performance of processes or services.

The purpose of a Six Sigma Project:

As the cost of material is rising and the competition is increasing day-by-day, organizations look for techniques that are capable of increasing the efficiency of their projects. Six Sigma projects focus on improving the efficiency of the organizations. By implementing the Six Sigma methodology, an organization can enhance the efficiency of their products, processes or services through identification and resolution of product or defects that might affect the organization and minimize the variation within the process. Every Six Sigma project follows a defined series of steps which include specific targets for improvement. Few examples include:
● Reduction in the process cycle time
● Reduction of scrap generated by a process
● Increasing customer satisfaction
● Reduction in the number of factory defects
● Reduction or elimination of costly reworks

The scope of a Six Sigma Project:

Project scope is a part of the Define phase in the DMAIC process and is included in the Project Charter. A project scope describes the limitations of a project. It keeps the team in alignment, on purpose, contained, focused, and motivated. The project scope might include:

● Beginning time and end time of the project
● Duration of the project
● Process boundaries of the project i.e what is within the scope and what is outside the scope.
● Sub-processes involved in the project
● Product lines of the project
● Locations involving the divisions, states, territories, and countries.

The most important component of the project scope is addressing the beginning and the end of the project. This is often outlined in the SIPOC diagram.

Importance of defining the scope of a project:

● The project scope explains what the project involves so that all stakeholders can understand what is involved
● It provides a roadmap to the managers in order to assign various tasks and schedule work and budget appropriately
● It helps the team members to focus on common objectives
● It prevents complex projects from extending beyond the fixed vision

How to define the scope of the project:

The criteria under which the scope of the project is defined is:

1. Deliverables: The end project delivered to the user and the deliverables generated by the project itself. These are called internal and external deliverables.
2. Data and functionality: Licensing agreements, payment processes, and customer management.
3. Technical structure: The focus of the project on infrastructure.

The value of a Six Sigma Project:

The value of a six sigma project is defined as the business case of a project. It is a document that uses the problem and goal statements of a project and converts them into a business value statement. There are five different cases:

● Strategic case – It is a compelling case for change that suits the strategic goals of the organization.
● Economic case – It is the solution that represents the best value for the problem.
● Commercial case – It is the recommended solution that is attractive to the market and can be obtained using suitable terms so it is commercially feasible.
● Financial case – It is the proposed financial investment that is affordable.
● Management case – It is the input required from all individuals involved in the project.

The steps to write a business case for a project:

The steps to write a business case are as follows:

1. Research the competition, market and any other alternatives for a project.
2. Compare it with the other approaches and finalize it.
3. Compile the final data and
4. Document

In addition to the above metrics, six sigma projects have seven different responsibilities. These are:

1. Leadership: The team defines the goals and the objectives in a six sigma process.
2. Sponsors: They are the individuals who understand what six sigma is and are dedicated to its successful implementation. They solve problems which might occur during the process.
3. Implementation Leader: These are the individuals who are responsible for supervising the team effort. They support the leadership team by ensuring the timely completion of the processes.
4. Coach: An individual who is an expert or consultant in Six Sigma who sets a schedule for the team and resolves any conflicts among them.
5. Team Leader: The person responsible for managing the team. They also act as a medium of communication between the sponsor and the members of the team.
6. Team Member: The individuals who work on a six sigma project. They have specific roles and work collectively with other team members.
7. Process Owner: The person who is responsible for the management and monitoring of various processes after the team has completed their work.

Six Sigma methodology focuses on a better understanding of what the customer requirements are and how the quality of the products delivered can be improved. It concentrates on waste reduction and cost reduction.