Author: Elizabeth Larson

Based on the Children’s World Cup Soccer Rules

I am not a big sports fan. My husband is an avid fan of baseball and American football, but I usually go about my business despite the frequent exclamations of euphoria and despair that reverberate throughout the house during sporting events. But a recent visit with our grandsons raised my interest in one sport-soccer (football). Having recently played World Cup soccer with four grandsons aged 8-2, where the rules were emphatically if inconsistently enforced, I thought about how these children’s rules apply to projects. Given my lack of knowledge about the real World Cup rules, I don’t have the slightest inkling of whether these kids’ rules even come close to reality, but they seem to work. So, at the risk of overusing the myriad analogies relating to children’s play to projects, here are five Kids’ World Cup Rules for successful projects.

Rule #1: Define the goal and how to reach it. In our kids’ game the goal kept changing. That is, how a goal was achieved was fluid. If the ball was kicked inbounds but bounced off the pole it probably didn’t count as a goal. Sometimes a goal could be scored by kicking the ball under the table, sometimes by missing the table entirely. On our projects not only do we need to have clear, unchanging business and project objectives, but we need a clear plan for how to get there. If either the goal or the set of project management and business analysis processes vary too much, the players will be confused, frustrated, and ultimately unsuccessful.

Rule #2: Focusing too much on the goal at the expense of your opponent can get you a yellow card, which is like a strike in baseball. Three of them and you’re out, according to the Kids’ Rules. The grandsons loved marching around the field silently carrying a small yellow block when an infraction had occurred. In soccer we need to get the ball from our opponent in order to make a goal, but not by infringing on others. Many project managers focus on meeting the project objectives without paying enough attention to our “opponents,” those who are not supportive of the project. Perhaps the project goals and objectives are at odds with their own, perhaps they are uncomfortable with our project processes or they don’t like the sponsor or other stakeholders, perhaps the end result of the project means that they that they will have to learn new processes, no longer be experts, have to learn how to use new systems or products, or perhaps even lose their jobs. There are lots of reasons why some stakeholders may not want to support the project. However, it is vital to recognize the stakeholders who are our opponents and develop strategies to bring them on board.

Rule #3: The red card-means you’ve really messed up and you’re expelled from the game. Fortunately our grandsons were not cutthroat and red cards were not abundant. On projects expulsion can happen when trust has been broken. Sometimes we don’t even know that we’ve been expelled. But if we feel like a pariah, or if a lot of communication is going on behind our backs, or if our team seems less motivated, if subject matter experts (SMEs) start showing up late or missing meetings, we may have been expelled.

Rule #4: When we mess up unintentionally we might get a green card. A green card means a minor offense has been committed, but the play can proceed. In Kids’ Rules it means an unintentional offense. As grandparents and as project professionals we’re going to mess up, but if it’s unintentional, we will probably be forgiven. As a grandparent I usually got a green card for using my hands by mistake. However, when I used my hands several times in a row even though I didn’t mean to, patience wore thin, I was told “that’s not how you play the game,” and I was given a yellow card. On projects there will be times when we mess up, but as long as it’s unintentional and infrequent people will understand. But when we mess up the same way with the same stakeholders over and over, we are viewed as incompetent — a definite trust buster.

Rule #5: Don’t argue with the referee. You could end up with a red card. The referee is the referee. My grandsons were proud of Team USA who despite the bad call acted professionally and were good sports. On our projects the sponsor is the referee. We will probably disagree with our sponsor from time to time, but as we know the sponsor (referee) isn’t always right, but the sponsor is always the sponsor.

There are several other rules that apply, like what happens when we don’t have a referee (neutral facilitator) or when we don’t devote our entire attention to the game, but we’ll end here, wishing you fun with family and success with your projects.

Last month we began our “fight” by exploring two estimating techniques that are often used on both Scrum and Waterfall projects (view here). The first was relative sizing (one kind of analogous estimating) and the second Delphi (called Planning Poker in Scrum). Scrum won both rounds (barely) because, although both techniques can be used on both types of projects, their usage in Scrum seems easier to understand, learn, and apply. I don’t know about you, but when I hear the terms Analogous and Delphi I think academics and hard work. When I hear about tee-shirt sizes and planning poker, I think fun.

This month, inspired by a debate on Agile vs. Waterfall, presented by the Phoenix chapter of IIBA, I want to compare Waterfall to Scrum in a variety of different ways. As I listened to the two sides during the debate, I was amazed at the number of the similarities, as well as the importance of the subtle differences. This month’s blog will explore both the similarities and differences.

Before I begin, I want to stress the point that neither one is a methodology. Neither is prescriptive. Waterfall is an approach. Scrum is a framework, part of the myriad Agile methods. Both allow for the use of a variety of techniques. To be effective, both require an appropriate amount of rigor, although we acknowledge that both approaches have been implemented in a wide variety of ways. For the discussion below, we’ll assume the appropriate level of rigor for the project at hand.

Similarities

There are many ways in which these two approaches are similar. Both:

1. Have processes to request, approve and prioritize changes. Both put focus for the approval and prioritization on the Business (product owner/sponsor/SMEs).
2. Stress the importance of communications.
3. Allow for more or less rigor, as appropriate.
4. Find communications easier when the teams are co-located.
5. Both face more challenges with virtual teams.
6. Have processes to manage the scope.
7. Estimate the work involved in business analysis whether phase (s), releases, iterations/sprints.

Differences

Many of the differences lie in how these processes are implanted. To understand the vast differences in implementation, we need to understand that many organizations have their own methodologies, so their processes for completing business analysis vary extensively. Also, many organizations use hybrids or “best of breed” implementations. With that in mind, let’s examine some differences between Waterfall and Agile.

Intricate, large projects. On large, intricate projects with many business and technical interfaces and impacts, with a variety of cross-functional SMEs or with many compliance regulations, there are advantages to the Waterfall approach. While these projects can also be implemented using Scrum, it is harder when there are project dependencies.

• Coding and testing. On the large projects I managed, we were always touching programs and test data that other teams needed and vice versa. It seems to me that following a detailed plan places less stress on all the teams. Even when slippage occurs or the team completes programs earlier than anticipated, following the plan and communicating variances in a more formal and proactive way is helpful to all the teams involved. Again, it can be done using Scrum or other processes, but I have found that following a plan is a stress-reliever.
• Incorporating changes. Again, when there are approved changes and there are significant project dependencies, it can be helpful to change the plan, so that a schedule for completing these changes can be determined and communicated to everyone impacted by the change. This is particularly true when the approved changes have significant impacts and can cause changes not only to work completed by the team, but by work already completed and tested by other teams.

The winner: Waterfall!

Defining requirements when they are highly volatile. Waterfall projects have approval points, often called toll or stage gates. When requirements are unstable, business analysis can seem to take forever and the sponsor may get frustrated with what appears to be analysis paralysis. I once had a sponsor tell me that he had never seen analysis take so long, but was surprised and delighted that the project get done so quickly once we had the requirements. Thoroughness in requirements definitely paid off. However, there was significant frustration as the churn was happening.

Scrum projects have the wherewithal to handle this kind of churn better in my opinion. User stories that are pretty well understood are closer to the top of the product backlog and are ready for inclusion in upcoming sprint(s) than “epics” that are less understood.

The winner: Scrum!

Managing scope and changes. On Waterfall projects, schedule, cost, and scope baselines are established (as well as others). These become project constraints. When changes are approved and prioritized by the Business, the sponsor, often upon the recommendation of the project manager, needs to decide which of the baselines will change. I have talked to many Scrum proponents who argue that Agile projects expect change, but Waterfall projects do not. This assertion is simply not true. I have yet to be on or hear of a Waterfall project that did not expect changes. Having said that, modifying the schedule, particularly when it involves changing dependencies, can be cumbersome and frustrating.

I think managing scope on Scrum projects is easier in many respects, most of which relate to the fact that having small sprints helps the framework accommodate changes with far less pain. In addition, I have seen more consistency in the way changes are requested, approved, and prioritized on Scrum projects.

The winner: Scrum!

I could go on with this comparison, but my little blog is turning into a full-fledged article, so I’ll simply list out areas where I think Waterfall wins and address them in more detail in future blogs.

Waterfall Wins in these Areas:

• Effectively using the role of the BA to define requirements completely, using a variety of elicitation and modeling techniques. Although Scrum is catching up, it still lags behind.
• Defining the business need and business case. Most of the visioning I have seen on Scrum projects has tended to be superficial. Again, this may be due to the way I have seen it implemented.
• Getting from the “as-is” to the “to-be.” Ensuring that the solution in general and software in particular supports business processes or if not, that the business is ready for the change with such things as new processes, training, the required sales, marketing and support resources, etc.

Of course Scrum wins in some other areas, too. More later!

Don’t forget to leave your comments below

Ask a business analyst (BA) who should define the business need and you might hear that it is the BA’s role to do so. After all, the business need defines the business problem or opportunity, which BAs have to understand in order to recommend appropriate solutions. BAs know that all requirements should link to the business need, so it is important to spend the necessary time to truly understand it.

Ask a project manager (PM) the same question and chances are they will say the same thing–that they are the ones who should determine the business problem or opportunity. They know that their project will not succeed if it does not help support organizational goals and if it does not solve real business problems. The business need becomes the project’s foundation. Just as requirements link to the business need, so does each project objective and deliverable. Since PMs are accountable for meeting the project’s objectives, many PMs want a part in defining the business need.

Who’s right? Who should define the business need? Does it really matter? I think it does matter, because the person who articulates the business need usually ends up owning the project. I do not believe it is in the best interest of the organization for either the BA or the PM to take ownership of the project. That is, they both need to be accountable for delivery of the end solution and for ensuring that that solution meets the business need, but not for the need itself.

Before we look at who should define the business need, let’s describe what a business need really is and its interrelationship with the project and the requirements. In order to meet its goals, an organization usually undertakes many projects, and the projects that have the greatest chance for success are those that help the organization reach its vision, strategic direction, and business objectives. Ideally projects are prioritized based on business need (problem/ opportunity) and the business case (costs vs. benefits), because the need describes the pain and the benefits describe the relief.  So before a project can really begin, the business need and business case are defined, either formally or informally.

Defining the business need occurs before the project is sanctioned by the project charter, that important document is ideally written by the sponsor, often with the help of a PM. The information in the project charter, including a high-level description of the end product or solution, is input into the requirements processes, which in turn produce the requirements that are input into the definition of scope at a level of detail sufficient for the planning processes. Of course, the requirements get further elaborated during the one or many phases of business analysis work, but each needs to help solve the original business problem or contribute to the business opportunity.

So who should define the business need? The PMs, because they have to meet the project objectives? The BAs because they have to define the solution requirements? I’m going to suggest that the person or group requesting the project should define the business need, and that person or group needs to be high enough in the organization to sell the idea, to get the organization enthusiastic enough about the endeavor to fund and prioritize it, and to rally the necessary business resources. I believe this responsibility is best handled by a sponsor, steering committee, regulatory or compliance body, or a fairly high-level Subject Matter Expert (SME). Project managers and business analysts are most effective when they are neutral facilitators, not owners. Both roles need to make recommendations and can certainly recommend which projects to undertake, but they are not the ultimate decision-makers.  They work with and advise decision-makers. However, when PMs and BAs move away from advising and into decision-making, facilitating and advising become far more difficult.

Although it’s the requesting organization (to use PMBOK speak) that defines the business need, I believe that the BA is in the best position to work with that person or group to help them articulate the real need and the extent of the need. BAs can help describe how bad the pain is or how great the opportunity. I think there is a vital difference between defining the need and helping the requestor define the need. That difference is one of advising versus deciding. And the PM? Although the PM can advise the sponsor on the writing of the Project Charter, the bulk of the project management work begins once the project has been approved and sanctioned and authority given to the PM.