Heavy vs. light methods for developing IT business solutions

Lou Russell

I am not a confident cook, and meals like Thanksgiving tend to make me neurotic. My approach at big dinners is similar to my old approach to large, complex projects: write down everything I want to make, assemble all the ingredients, orchestra an appropriate set of dependencies (what needs to come out of the oven first?) and then implement with the goal that everything be hot and on the table, hopefully edible, at the same time. This goal was rarely met. More usually, the meal was completed late, with many items of different temperatures. Often, one or my items were burned to a crisp or raw, and unedible to most.

Think about the characteristics of this approach to my meal project and how it may be similar to your approach to projects. Notice the following:

• A large, plan up-front (in this case a list) detailing and anticipating everything that is to be done.

• A schedule, with dependencies of the sequence of activities.

• A guess (in this case, not educated) of how long each activity would take.

• Limited resources (me, one oven, and worse, one microwave!).

• Missed goals.

My mother-in-law, who was a wonderful cook, often had a similar menu, but her approach to implementation was much more flexible. She would adjust and flow to whatever she was making. She would leverage her experiences to deal with whatever came up. There was always food available the whole time so we could all snack as we waited for dinner to be ready. In fact, it seems to me we would eat with her all day.

Think about the characteristics of this approach to her meal project and how it may be dissimilar to your approach to projects. Notice the following:

• A general idea of the “big picture,” but no detailed list and know belief that everything could be anticipated.

• Prioritization of what to work on first—whip up some carrot and celery sticks to keep everyone busy while you work on the next item.

• A schedule only for the menu item she was working on right now, and this was kept in her head, since it was not very large.

• A guess (in this case, not educated) of how long each activity would take in the immediate menu item only.

• An adjustment of prioritization whenever a surprise occurred, in this case, a grandchild requesting an Oreo.

• Limited resources (the same as my project) but the added disadvantage of having volunteer helpers who really just got in the way and had to be given busy work to do.

• All goals met, although the goals changed from the start to the finish.

• A joy in the process.

The project characteristics were the same: time constrained, pressure to meet critical requirements, complexity, massive change, nagging customers and changing goals. The critical factors that differed were:

• Her beliefs versus my beliefs

• The development (meal making) process.

Notice that the actual cooking techniques implemented may have been pretty similar, and that these were not as much of a factor to success.

Today, IT is struggling with its own inability to cook. We, as an industry, have given lip service to the need to develop large plans and implement, as a whole, large buffets of technology, never really getting anything to the table better than lukewarm. Many project offices force IT project managers to submit Project Charters, but rarely are they ever looked at again. In honesty, the IT project environment is chaotic and complex, and any attempt to guess what will happen is almost always wrong before the ink dries.

If we step back and look at the superstars that really deliver in our IT organizations, they approach projects more like my mother-in-law approached cooking, although they are masters at pretending to follow the existing processes. While the project manager generates the required corporate paperwork, the others implement their own process based on experience. This process is much more flow oriented. Experienced, successful IT project managers and staff understand that there is no way to anticipate the glitches that might occur. It is rarely, if ever possible to anticipate duration and resource allocation accurately. The only constant is the due date, usually fixed, and the focus on prioritization and delivery of as many features as they can within this window.

The customer is constantly receiving communication and value; some things get thrown away as newer ideas are grown but everything moves toward the good of the business. The customer plays a critical role in this type of approach—they are depended on to prioritize the work to be done. The truly successful IT projects always have heavily vested customer participation.

But there have been success stories where the customer has not been as involved, a much more normal situation in IT. In this case, the process is modified, and prioritization is done by IT developers. This is certainly not the right person to make these decisions, but in lieu of a customer voice, there is no choice. In actuality, many IT professionals have so much experience in the code of the business area that they may know even better than a single customer contact how the business area works or doesn't work, as is more often the case.

To me, this is the difference between the current heavy and light approaches to IT business solution development. Traditionally, IT organizations have tried to pick the methodology panacea that will enforce quality into projects independent of the resources assigned, the business context or the project constraints. If you are a practitioner in IT, you will remember the following methodologies—structured methods, Systems Engineering, Information Engineering, Object Oriented, Rapid Application Development (RAD)—and the following tools—Data Flow Diagrams, Entity Relationships Models, CRUD Matrices, Object Models, Event Diagrams, Prototyping, and CASE.

Even people like me, who are completely biased to the need for analysis and planning, will admit that these projects quite often lost the focus on the business. Instead, they tended to flounder with an unhealthy focus on the methodology, the project for the project's sake. The customer became an evil adversary blocking the implementation of the Holy Method. The need of the business was replaced by a need for development Nirvana.

The field of chaos theory has been one of the drivers of this new approach (check out Margaret Wheatley's book “A Simpler Way”). A light methodology, such as Extreme Programming (XP) [for more information, check out the books by Ken Beck] or Adaptive Development (AD) [for more information, check out the book by that name by Jim Highsmith] takes a more long-term improvisational approach tempered with short term structure. Where prototyping methodologies (RAD) seem to have strayed too far to the “loose” side, and traditional methodologies (such as structured methods) seem to have strayed too far to the “tight” side, light methodologies seem to be working to create a pragmatic middle. Recently, the people who are most actively working to define this type of approach—Ken Beck, Jim Highsmith, Alistair Cockburn and others—the term light methodologies has been replaced with a more complimentary and accurate term: Agile Methodologies.

Consider my mother-in-law's cooking method: although she had a vision for what the final meal would be, she did not limit herself to this vision but let it fluctuate. As I cook, my list becomes the focal point, driving my frustration levels higher, which further hamper my ability to change my approach when needed by my “customers.”

What is a Methodology?

A methodology is an approach or strategy. Inherent in this approach is a philosophy, a set of assumptions or mental models based on what creates success or failure on a development project.

Methodologies specify the tasks that must be done to meet the goals of the project; in fact, they generally specify the most tasks you would ever want to do. One of my favorite Tim Lister quotes is “If you've done two projects using the exact same tasks of a methodology, you have done them both wrong.” In this sense, then, methodologies provide a repeatable process useful on all projects, but only when tempered and adjusted for the specific project at hand.

I like to call this flexible structure, but this flexibility is a challenge for people who love order. The ability to pick and choose tasks pertinent to a project is not a capacity common in IT. In fact, when the list of tasks becomes too large to manage, a more common approach is to abandon them all and “wing it.”

It is not unusual for us to teach project management workshops for IT organizations that either do not have a development methodology or have not yet settled on a standard (have many). Many of our learners stumble into class hoping that the project management activities we teach will “tell them what to do.” It is critical that we quickly educate them on the fundamental but often confused difference between project management and development methodologies—simply, the development methodology tells you what you should do (tasks) and the project management methodology tells you how to plan, organize and control this doing. So, creating a work breakdown structure (WBS) for a project is a project management activity but the boxes of this model contain the steps suggested (hopefully) by the development methodology.

The Light Approach

In the light approach, the project as a whole has no work breakdown structure, because it is impossible to know what the activities are at the start. Instead, there is a high level list of all the features the business requires. This list is prioritized by the business given the time and cost estimates provided by the IT professionals. Iterative phases replace the “whole” project, each one lasting a small amount of time, say six weeks. The customers pick which six weeks worth of features they want in each iteration.

The overall Project Charter is not that different: there is a high-level statement of scope, there are business objectives, systems objectives, risk analysis and constraint definition. The Iteration Plan is where the rigor resides with very specific tasks and resource allocations for the next six weeks. At the end of an iteration, the team reviews how much “velocity” was actually delivered. If the team delivered four weeks worth of work in six weeks, which is a pretty good velocity rate since that means the team was able to work directly on the project 66% of the time, then the customers pick four weeks of features for the next iteration.

The end of the project is not the same as it used to be. The project ends when the customer says it ends, and therefore, funding stops. In some sense, the project is in maintenance from the very start—there are no criteria for done. When the business and system objectives are met from the customers’ perspective, the project is finished, but it is never “done.” In truth, no IT project has ever been done, and the distinction between development and maintenance has always been more of a political decision than a business decision.

Exhibit 1

Exhibit 1

Mental Model Changes

There are specific mental models or beliefs that differentiate heavy from light developers, just as there were different cooking beliefs between my mother-in-law and myself about cooking. Realize that these beliefs may not be universally held, and may not relate specifically to the methodology, but in my opinion, do appear prevalent. These are contrasted in Exhibit 1.

There is some discussion right now about whether there is really anything new in the light approaches. If you were to walk up to two different IT projects—one using a light approach and one using a traditional approach, you might not see anything too different at first. But look closely and you will notice two critical differences: the customer is present on the light project, and the developers seem more emotionally engaged.

Collaboration

Collaboration has been identified as a key critical success factor for light methodologies. Without dedicated customer involvement, prioritized, business iteration is not possible. In other words, without people to be responsible and have the authority for making key prioritization choices in a quick way, a short-term iteration will become a long-term, traditional project.

The first step is to have dedicated resources from the customer area with both responsibility and authority. The second step is to build the team dynamics required to collaborate. Collaboration requires bi-directional trust, and this kind of trust can only be earned. The light method gives the entire team small, challenging but possible targets creating a clear vision. This clear vision creates the team synergy necessary to succeed. One success, or even one failure in this case will increase the trust between team members since the vision is shared.

Which is Best?

Certainly, there are lots of similarities between the manifestations of both, but the beliefs behind them are very different. The heavy beliefs follow a manufacturing metaphor, while the light beliefs seem to focus more on a new product development metaphor. Our world, with its increasing global competition, is following a highly time constrained, fluctuating requirements agenda. Treating each IT project as a new product seems to fit better with the context of business today.

What Does It Look Like?

You may be like me, and right now you are asking yourself, “Okay, I get the metaphor, but what would this look like on a real project?” Here are three examples of how this approach would look/feel/be when applied to different situations, from simplest to most complex, the last of which is an IT example.

Designing a Custom Coffee Maker

Light

Meet with the customer; create a high-level list of features the coffee maker will do. Get signoff on the requirements.

Chunk these into features that could be delivered in six-week intervals. Ask the customer to prioritize the list.

Create a detailed plan to implement the first feature including a detailed user acceptance test case.

Implement the plan for the first feature (for example, make coffee using coffee ground and cold water). Deliver the feature to the customer, involving them with questions whenever necessary.

First feature is delivered, and approved by the customer. The time it took to deliver is used for a baseline to predict the sizing of future features. The customer is asked again to reprioritize, and pick the next feature to be delivered in six weeks based on the new estimates.

Repeat step 3, redoing existing features as necessary to add new features until the entire solution is in place.

Heavy

Meet with the customers.

Model the processes required for the custom coffee maker.

Get signoff on the requirements to ensure that the customer does not change their minds.

Create a detailed project plan of the entire project, and assign resources to tasks. Begin.

Project progresses. Different individuals working on different pieces may contact customer with similar or different questions. Difficult to assess overall status as plan is challenged with normal disruptions and surprises. Schedule problems early are addressed by shortening future tasks, like testing.

Complete project. Customer requests many modifications. Project becomes a maintenance project rather than a development project.

Design a One-Day Workshop

Light

Meet with the customer; create a list of course objectives. Ask the customer to prioritize the list. Chunk these into features that will be delivered each day. Create a detailed plan to implement the first feature including a detailed user acceptance test case.

Implement the plan for the first feature (for example, determine the high-level procedure steps). Deliver the feature to the customer, involving them with questions whenever necessary.

First feature is delivered, and approved by the customer. The time it took to deliver is used for a baseline to predict the sizing of future features. The customer is asked again to reprioritize, and pick the next feature to be delivered in six weeks based on the new estimates.

Repeat step 3, redoing existing features as necessary to add new features until the entire solution is in place.

Heavy

Meet with the customers; determine all the learning objectives required, do a complete gap analysis, define flow of class, overheads, etc.

Create a detailed project plan of the entire project, and assign resources to tasks. Begin.

Project progresses. Different individuals working on different pieces may contact customer with similar or different questions. Difficult to assess overall status as plan is challenged with normal disruptions and surprises. Schedule problems early are addressed by shortening future tasks, like testing.

Complete project. Customer requests many modifications. Project becomes a maintenance project rather than a course development project.

Design an E-Commerce Site

Light

Meet with the customer; create a high-level list of features the e-commerce site will do. Chunk these into features that could be delivered in six-week intervals. Ask the customer to prioritize the list. Create a detailed plan to implement the first feature including a detailed user acceptance test case.

Implement the plan for the first feature (for example, accept MC/VISA/AE). Deliver the feature to the customer, involving them with questions whenever necessary.

First feature is delivered, and approved by the customer. The time it took to deliver is used for a baseline to predict the sizing of future features. The customer is asked again to reprioritize, and pick the next feature to be delivered in six weeks based on the new estimates.

Repeat step 3, redoing existing features as necessary to add new features until the entire solution is in place.

Heavy

Meet with the customers; model the processes required for the e-commerce site. Get signoff on the requirements to ensure that the customer does not change their minds.

Create a detailed project plan of the entire project, and assign resources to tasks. Begin.

Project progresses. Different individuals working on different pieces may contact customer with similar or different questions. Difficult to assess overall status as plan is challenged with normal disruptions and surprises. Schedule problems early are addressed by shortening future tasks, like testing.

Complete project. Customer requests many modifications because they are new to e-commerce and didn't really know what to expect. Project becomes a maintenance project rather than a development project.

Impact on Project Management

What is the impact on our approach to Project Management? How does this type of approach impact the use of project management tools and techniques? How does this type of approach align with the PMBOK® Guide?

Certainly, the line between development and project management is even more blurred than it has been. The project management and development activities were confused previously, but they are so interwoven in a light approach that it hardly makes sense to differentiate between them. Will this threaten the discipline of project management? Will turf wars prevent adoption of this innovative approach? Only time will tell.

The light approach is not revolutionarily different, in fact, in may be more similar to the way “expert” teams have delivered systems. There are things tightly in sync between the two methods.

Roles

The customer role and the developer role are clearly delineated. Each is responsible for specific expertise. The customer is the only one who can define the features required and prioritize them. The developer is the only one who can determine how long and how many resources it will take to build each feature, information critical to the customer's ability to make reasonable choices.

For the project to be successful, these roles must be tightly honored. For example, the customer cannot challenge the estimate, or ask the developer to build the same scope with half the resources. Likewise, the developer cannot add features that the customer doesn't want, or change features requested without approval. Many projects fail now because these roles are not enforced. A friend of mine made an argument that if just these roles were reinforced, most methodologies would work. They'd certainly work more effectively.

Estimates

In both sets of methods, estimates are critical to making strategic choices. The primary difference is that traditional methods dictate methods for the entire project, which are generally impossible to predict. In the light method, estimates are required for features, with much more likelihood that they will be accurate because they are smaller and less complex.

Testing

The light approaches emphasize and enforce testing. Ultimately, the final judge of the completeness of a feature is the customer— no other test is really as critical. There may be features, for example, related to security that are judged by an IT auditor who plays the role of the customer, but even in this situation this customer completely owns the judgment of completeness.

Traditional methodologies have always included testing, but when the schedule was challenged, as it always is, the testing was one of the first things skipped. This is not possible with full customer involvement because minimally, their opinion become guarantees testing. It ain't done till they say it is.

Tracking

A core part of a light approach is historical tracking of estimates, and the adjustment of this velocity in later iterations. The inability to adjust for surprises is one of the downfalls of traditional approaches. The lack of historical information, since all projects are so different, makes it impossible to estimate accurately for any future projects.

Project Management Tools and Techniques

Treating a project iteratively has a serious impact on software tools. If there is no need to build a huge, complex, critical path oriented plan, than there is less need for a complex software package to keep track of the infinite details.

In many cases, the iterations are so small (six weeks) and so focused to a specific feature that mechanizing the activities is not necessary. Maybe a couple of flipchart sheets with some Post-its will do the trick. In some cases, it might be useful from a historical standpoint, but the overhead to put these items into a complex software tool may not be worth the tradeoff of less features.

The PMBOK® Guide

The PMBOK® Guide clearly details all the factors that must be managed for a project to be successful. To be sure, it is geared toward a more traditional approach to development, but all the factors must still be present whether a light or heavy approach is taken. In fact, much of the work down within the New Product Development SIGs has moved toward the lighter approach, for example, phased-gate oriented activities.

Summary

There is no holy grail. There is no single methodology that will solve all the challenges of implementing technology based business solutions. There is no methodology that will work perfectly for any IT project, and there is not methodology that will compensate for untrained developers.

However, when the requirements are unstable and complex, the time is constrained, and the business application is critical, the mental models for the light methodology seem to make the most reasonable sense and hold the most likelihood of success. In contrast, heavy methodologies still make sense for applications that have very clearly defined and unchanging requirements.

However, it remains to be seen how a light approach can be used to implement a large, global, ERP application. If your company is implementing something like SAP globally, who is the customer? Would a company be able to give a single or small group of people the authority to make business decisions real time on an application like this? If they could not, would the project ever be able to be successful? There are many other unanswered questions like: who prioritizes the features if multiple business areas are involved? Can you apply a light approach to a solution that requires decision-making by committee? Can decision making by committee ever be completely successful, or is it driven by compromise, and therefore, a failure to all?

Time will tell whether the light approach scales up to this type of initiative. In the interim, experiment with it yourself. Apply this to small projects and notice the power of the approach.

It creates no benefit to any of us to spend time arguing about which is best, whether there is any difference, whether history has repeated itself or whether Y2K was a hoax. Instead, IT developers must open their minds to new possibilities, and challenge the beliefs that have prohibited them from meeting their customers’ needs in ways required by the current marketplace. As Stephen Hawrysh and Jim Ruprecht said in the November 2000 issue of the Cutter IT Journal:

“The moral of the story is that there is no one-size-fits-all software development model, and it is nuts to try and force one into place. Software development shops need a taxonomy of methodologies—one that includes LM/XP [light] as well as the more rigorous methodologies.”

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA

Advertisement

Advertisement

Related Content

  • Project Management Journal

    Identifying Challenges and a Research Agenda for Flow in Software Project Management member content locked

    By Dennehy, Denis | Conboy, Kieran Flow and its associated tools and metrics are increasingly being reported as an approach used to achieve continuous deployment of software and delivery of value in software development projects. Yet…

  • PM Network

    Escaping Pilot Purgatory member content locked

    By Waity, C. J. Pilot projects can bridge the gap between a brilliant idea and a valuable product—but only if the bridge is successfully completed and built to scale. And in the age of disruption, that doesn't…

  • PM Network

    Hands-On member content locked

    By Karunaratne, Charmaine Although the software development life cycle (SDLC) is an important part of any software project, IT project managers rarely seem to raise the topic. Instead, they leave it to the development teams…

  • PM Network

    Best of Both member content locked

    By Graetsch, Ulrike Maria When leaders at rapidly growing organizations establish a project management office (PMO), they're often seeking better control over which projects are started, more oversight of projects in…

  • Project Management Journal

    How to Buffer the Family Costs of Project Citizenship Behavior member content locked

    By Zhong, Rui | Xia, Nini | Hu, Xiaowen | Wang, Xueqing | Tiong, Robert Previous studies have mainly concentrated on the desirable aspects of project citizenship behavior (PCB) but largely ignored its dark sides. We seek to fill in this gap by exploring whether and when…

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.