Managing software projects effectively: Key points project managers should know

Software project management roles continue to change is tool and process improvements become available. In this chapter learn how to effectively manage your team. Learn where experts say key focus areas lie in this chapter excerpt.

software project management bookSoftware development, much like manufacturing is drastically changing. In order to stay on top, project managers need to accept and adapt to change. This chapter provides focus areas for PMs concerned about: risks, cost, complexity, business climate and team competency.

Characteristics of the Project

When I think of the project-management landscape, I think of it at a higher level of abstraction than the seven variables discussed earlier. In keeping with my penchant for the simple and intuitive, I visualize it as a simple two dimensional grid like the one shown in Figure I.4. The first dimension relates to the goal of the project. It has two values. The goal is either clearly specified (therefore completely known) or not clearly specified (therefore not completely known). 

The second dimension relates to the solution, or how you expect to reach the goal. That also has two values. The solution is either clearly specified (therefore completely known) or not clearly specified (therefore not completely known). If we intersect these two dimensions as shown in the figure, we have defined a four-category classification of projects. It is important to note that the boundary between clear and not-clear is a conceptual boundary. It is not quantitatively defined, but is only conceptually defined. This classification is simple, but it is inclusive of every project that ever was or ever will be. That is, every project must fall into one and only one of these four quadrants:

  • TPM: Traditional Project Management (linear and incremental PMLC models)
  • APM: Agile Project Management (iterative and adaptive PMLC models)
  • xPM: Extreme Project Management (extreme PMLC models)
  • MPx: Emertxe Project Management (extreme PMLC models)

The projects in the TPM quadrant are those for which the goal and the solution are clearly defined. These will be simple projects that have been repeated a number of times in the past. There will be well-developed templates for all, or significant parts, of these projects. Because these projects are very familiar to the organization, the requirements will be known as well. Having complete requirements means that the solution will be clearly defined and the complete work breakdown structure (WBS) can be generated. TPM models will work quite well for these projects.

Next in order of increasing uncertainty are projects in the APM quadrant. The range of projects will be from those where the goal is clearly defined and most of the solution is known (perhaps with the exception of choosing how to render some features) to those where very little of the solution is known, and it must be discovered as part of the PMLC model chosen for managing the project. Because some of the solution is unknown, the risk associated with these projects is much higher than the risk associated with projects in the TPM quadrant. The successful completion of such projects will be critical to the organization. The business value must therefore be high enough to warrant taking on these higher-risk projects. Obviously, the requirements can't be clearly and completely defined because that would imply knowing the complete solution. Therefore a complete WBS cannot be generated, and TPM Models cannot be used. What's needed instead are PMLC models that incorporate solution-learning and -discovery features so that the complete solution can be found as part of executing the project. Our focus in this book will be on APF approaches which fall in the APM quadrant.

Next in the order of increasing uncertainty are projects in the xPM quadrant. For these projects, neither the goal nor the solution is clearly known; they must be concurrently learned and discovered as part of executing the project. These are usually R&D projects for which the risk of failure is very high. For these projects, the best-fit PMLC model must embrace a great deal of uncertainty and include investigative cycles that are designed to converge on a goal and a solution to support that goal. Even when that may be done successfully, there remains the question of business value. Does the solution to the now clearly defined goal offer sufficient business value to be useful to the organization? A good example of this situation is the project that eventually led 3M to the Post-it Note product. The glue produced from the original project did not deliver a product that had business value as originally defined, and sat on the shelf for about seven years until someone found an application with business value.

The discovery of that business value came from a project from the MPx quadrant. Projects in the MPx quadrant may seem like nonsense projects at first glance. Are there meaningful projects that consist of a solution looking for a problem? In fact there are. Wal-Mart's initial investigation of the newly introduced RFID technology provides a good example. The question Wal-Mart was asked in this MPx project was: "Can you find an application (the project goal) of RFID technology (the solution) that has business value?" This sounds like an xPM quadrant project, but with the sequence reversed. That is why I call these projects Emertxe projects. If you haven't already observed, Emertxe is Extreme spelled backwards. Both the xPM and MPx quadrants are heavily populated by R&D projects. The xPM-quadrant projects are projects looking for a solution to a fuzzily defined goal. The MPx-quadrant projects are projects looking for an application (the goal) of a technology (the solution or some variant of it) that has business value. xPM and MPx projects use the same PMLC model. An MPx project can be very simple or very complex. Refer to Chapter 8: APF in the Extreme for more details.

The best-fit quadrant can change as the project progresses. For example, early in a project's life cycle, the goal may be clearly defined but the solution not clearly defined. That places the project in the APM quadrant, and the best-fit project management process for that quadrant can be chosen. As the project progresses, the solution may be discovered and become clearly defined. The project then moves to the TPM quadrant. The best-fit PMLC model approach may be changed from one in the APM quadrant to one in the TPM quadrant. There are a number of considerations when one is faced with this decision. They are discussed in Chapter 9: APF Frequently Asked Questions.

I contend that APM represents a class of projects that is continuously growing. I have traveled throughout the U.S., Europe, and Asia and have asked project managers what percentage of their projects falls into each of the quadrants. With very little variance in the estimates, they believe that 20 percent of their projects fall in the TPM quadrant, with 70 percent in the APM quadrant and 10 percent split between the xPM and MPx quadrants. I believe that the industry a company is in will have an impact on these percentages, but I don't have any data to support that view. For example, in the building-construction industry, there should be a higher percentage of projects in the TPM quadrant than there would be for the financial-services industry.

My colleagues have confirmed these percentages from their own client experiences. There is a lot of consistent anecdotal evidence to support that distribution. I just haven't come to a firm conclusion yet, since much of the APM quadrant is new. After we have gained more experience with APM projects and I hear more from my colleagues, we'll have a better understanding of this landscape.

If we try to fit projects into the TPM quadrant when they really belong in the APM quadrant, then we are heading for trouble. This is what many have been doing even though they know that their approach is rigged. Many are not ready to embrace the alternatives. The results of a rigged approach range from mediocre success to outright failure. For years I have advocated that the approach to the project must ultimately be driven by the seven variables listed earlier. Once we have decided that the project is a TPM or APM or xPM project, then we can take these seven variables into account as we choose the specific best-fit PMLC model aligned with the chosen quadrant. The APM quadrant is the focus of this book. The other quadrants will be referred to as needed to complete the discussion.

Even at this early stage in the discussion of the APM quadrant, you should be able to list some of the characteristics you would expect to see an APF PMLC model possess if it is to be successful. Here's my list:

  • APF requires a new mindset—one that thrives on change.
  • APF is not a "one-size-fits-all" approach—it continuously adapts to change.
  • APF utilizes a just-in-time planning approach.
  • APF adapts tools, templates, and processes from TPM and xPM approaches.
  • APF is based on the principle that you learn by discovery.
  • APF guarantees "if you build it they will come."
  • APF seeks to get it right every time.
  • APF is client-focused and client-driven.
  • APF is grounded in an immutable set of core values.
  • APF delivers maximum business value.
  • APF eliminates all non-value-added work.
  • APF approaches are less costly and require less time to execute than do TPM approaches.
  • APF meaningfully and fully engages the client as primary decision maker.
  • APF is based on a shared partnership between client and team.
  • APF works—100 percent of the time! No exceptions!

Do I have your attention? Good! Read on and find out how APF approaches can significantly improve your company's project performance and bottom-line impact.

Business Process Life Cycle

APF will have to integrate with other processes. They include software and systems development life cycles, product development life cycles, process improvement life cycles, and problem solving life cycles. There may be others as well. APF should be integrated into these business processes rather than having the business processes integrated into APF.

Project Management Life Cycle

As a project-management approach, APM must adapt to the project. It will not work effectively if it forces the project into its own set of rules and conventions. There will be several APM approaches that might be chosen for these projects. Among the current APM approaches, the industry includes the following software-development models:

  • Adaptive Project Framework (APF) (the one discussed in this book)
  • Adaptive Software Development (ASD)
  • Feature Driven Development (FDD)
  • Dynamic Systems Development Method (DSDM)
  • Evolutionary Development Waterfall
  • Prince2
  • Scrum
  • Rational Unified Process (RUP)
  • Microsoft Solution Framework (MSF)
  • Crystal
  • xP
  • and several others

Except for APF, a detailed discussion of these APM models is beyond the scope of this book. For more detail on TPM, APM, xPM, and MPx, see my book Effective Project Management: Traditional, Agile, Extreme, Fifth Edition.3

Profile of the Project Team

Alignment between the project-management approach and the team's skills and competencies is essential for project success. For example, if the project is very complex and will require a lot of creativity and outside-the-box thinking on the part of the team, then choosing a team filled with professionals who like to follow a recipe won't work. If this is your team's profile and you have an APM or xPM project, this may require using an approach that isn't the best fit for the project but does match the team strengths and preferences.

All APM approaches require a project team consisting of senior-level professionals who can work unsupervised. An APM project is no place for a rookie project manager or team member. Many APM project teams must be colocated. While there are some workarounds to avoid having a colocated team, they come with attendant risks. We'll discuss the implications in Chapter 9: APF Frequently Asked Questions.

Profile of the Client Team

Just as the chosen approach must align with the team, it must also align with the client. For example, clients of the take-charge type that are quite comfortable with the lead position might resist an approach where they have little or no say in what happens. If they are capable of taking charge, choose an approach where they can take charge (Scrum, for example). You will always be there as backup if they tend to stray outside of scope.

Supporting Technology
Project Management Is Organized Common Sense

I keep things simple and intuitive. One way to simply and intuitively define project management is that it is a set of tools, templates, and processes designed to answer the following six questions:

  1. What business situation is being addressed by this project?
  2. What do you need to do?
  3. What will you do?
  4. How will you do it?
  5. How will you know you did it?
  6. How well did you do?
  7. Let's quickly look at the answers to these questions.

    1. What Business Situation Is Being Addressed by This Project?
    The situation is either a problem that needs a solution or an untapped business opportunity. If it is a problem, the solution may be clearly defined and the delivery of that solution should be rather straightforward. If the solution is not completely known, then the project-management approach must accommodate the learning and discovery of that solution. Obviously, these will be higher-risk projects than TPM projects, simply because the deliverables are not clearly defined and may not be discovered despite the best efforts being extended.

    A project to take advantage of an untapped business opportunity can be done in several ways, discussed in Chapter 1: Overview of the Adaptive Project Framework.

    Keep in mind that your project may be competing for resources with other projects that are addressing the same business situation but from a completely different perspective. For example, your project may be attacking one part of the problem while another project is considering a different part of the problem. It would be good if you knew this, because integrating the two projects into a single program may be cost beneficial. At least you would have more points of view to consider. The importance to senior managers of finding that solution or taking advantage of that untapped business opportunity will also compete with the importance of other project proposals.

    2. What Do You Need to Do?
    The obvious answer is to solve the problem or take advantage of the untapped business opportunity. That's all well and good; but given the business circumstances under which the project will be undertaken, it may not be possible. Even in those rare cases where the solution is clearly known, you might not have the skilled resources to do the project; and if you do have them, they may not be available when you need them. When the solution is not known or only partially known, you might not be successful in finding that heretofore-unknown solution. In any case, you need to document what needs to be done.

    3. What Will You Do?
    The answer to this question will be framed in your project goal and objectives statements. Maybe you and others will propose partial solutions to the problem or ways to use the untapped business opportunity. In any case, your goal and objective statements will clearly state your intentions.

    4. How Will You Do It?
    This answer gives your approach to the project and your detailed plan for meeting the goal and objective statements discussed above.

    5. How Will You Know You Did It?
    Your solution to the problem or approach to the untapped business opportunity will deliver some business value to the organization. That is your success criterion. It will have been used as the basis for approving your doing the project. That success criterion may be expressed in the form of Increased Revenue or Avoided Costs or Improved Services. IRACIS is the acronym for these three areas of business value. Whatever form that success criterion takes, it will be expressed in quantitative terms so that there is no argument as to whether you achieved the expected business results or not. As part of the post-implementation audit, you will compare the actual business value realized to the estimated business value stated in the project plan that justified doing the project in the first place.

    6. How Well Did You Do?
    There are really four questions that comprise this question. The first and most important is, how well did your deliverables meet the stated success criteria? The second is, how well did the project team perform? The third is, how well did the project-management approach work for this project? The fourth is, what lessons were learned that can be applied to future projects? The answers are all part of the post-implementation audit.

About this book

"This chapter excerpt is from the book, Adaptive Project Framework: Managing Complexity in the Face of Uncertainty, authored by Robert Wysocki, published by Addison-Wesley Professional, ISBN 0321525612, Feb. 2010, Copyright 2010 Pearson Education, Inc.

 

This was first published in March 2010

Dig deeper on Software Project Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close