Declaration of Interdependence

Thoughts on DOI #6 – Situationally Specific

And finally, I conclude my explanation of the Declaration of Interdependence with the sixth statement about situationally specific strategies and tactics.

#6 – Situationally Specific

  • We improve effectiveness and reliability through situationally specific strategies, processes and practices

For me this was the hardest of the six statements to accept. I had wanted something stronger – a recognition that the most effective solution couples the engineering discipline with the project management discipline and allows them to feed off each other intelligently. I’ve learned this from FDD. The project management aspects of FDD are different because the Coad Method of software engineering enables a different way to think about project management. Project management in FDD isn’t some generic task-centric formula. It’s based on the architecture and analysis method. The reporting isn’t standard earned value rather it’s based on the production of features. I believe that when project management and engineering disciplines are combined a more effective process is delivered. I didn’t get that. So I settled for this message about situationally specific opportunities which gets us most of the way there.

So for me, the DOI is embracing the idea that it is OK to argue for different approaches and to go ahead and customize project management techniques and to couple them to knowledge of how the engineering technique works. It’s OK if you can show that it is leading to a more economically effective solution.

    Thoughts on DOI #5 – Team

    And yet more explanation of the Declaration of Interdependence with the fifth statement focused on teams.

    #5 – Team

    • We boost performance through group accountability for results and shared responsibility for team effectiveness

    Taylorism in the 20th Century was all about the cost accounting notion that you optimized the whole by focusing on efficiency at the individual level. With the DOI we are calling this out to be wrong. We’re taking a Peter Drucker / Michael Porter style view that business is done in a value chain. The optimal performance is where everyone in the value chain partners together and has a vested interest in the success of the whole chain. It is this notion which led us to the statement "shared responsibility for team effectiveness".

    "Group accountability" captures the notion of "personal safety". Personal safety is the flip-side of courage. Why should you need to be courageous? Because you do not live in an environment of personal safety! Hence, group accountability says, "we are all in this together. Together we succeed or together we accept responsibility for our failure." By creating an environment of personal safety, we believe that individuals are motivated to do the right thing for the optimal performance of the whole system and not take a local decision to protect themselves which is sub-optimal to the global performance.

      Thoughts on DOI #4 – Innovation

      And more explanation of the Declaration of Interdependence with the fourth statement focused on innovation.

      #4 – Innovation

      • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference

      We wanted to capture something in the DOI which expressed the notion that we view individuals as assets in a business rather than faceless resources which are somehow magically interchangneable and fungible in a 3-sided iron traingle tradeoff. People are the ultimate source of value is a recognition that modern work is knowledge work. Knowledge is value. People create that knowledge. The creation of new knowledge is an act of creativity which generated innovation. This happens better when you create an environment where people are viewed as assets and encouraged to take risks and make a difference. This isn’t really a project management practice rather a good modern management practice

        Classifying Uncertainty Revisited

        This new entry replaces an earlier one Sometimes I just get it wrong. Here is an attempt to get it right second time around. This is a supplement to the content of Chapter 4 – Dealing with Uncertainty. The diagram reflects the 4-types of variation identified by De Meyer et al in their article from Winter 2002 edition of MIT Sloan Management Review, Managing Project Uncertainty from Variation to Chaos [PDF].

        We can use this model to better understand a system for software engineering in a given market.  Variation is where assigned cause has been eliminated and only chance cause exists within a known and understood system. Foreseen Uncertainty is where there are identifiable risks and understood issues which affect the delivery of the project but the basic market for the deliverable is understood and the business model or go-to-market strategy is understood. However, there is sufficient uncertainty that assignable cause variation will be observed and must be dealt with through aggressive issue log management.  Unforeseen Uncertainty will feel out of control most of the time and what gets delivered won’t be exactly what the customer wanted or when they wanted it. This could be because the software development is happening with a new paradigm of tools or method – when teams start using MDA or DSLs for example – but it may also occur in new markets where the business model is not understood and the degree of variation cannot be predicted. The answer is to iterate frequently and plan adaptively. It is primarily this class of project which Doug DeCarlo addresses with his Extreme Project Management method. Finally, there is Chaos, the land where we don’t know what we don’t know and we are trying to find out – neither the market, the business model, the customer base, the product features, or the technology are understood. It’s the land of research projects.

        From a project management perspective, knowing where our project lies in this continuum is important for setting expectations. With Variation we can simply create a common cause buffer based on existing process control limits. With Foreseen Uncertainty, we create a risk management plan which may contain some mitigation approaches which amount to further buffer. In some industries this is called insurance. Insurance works just like common cause buffering but the aggregation is at a higher level. Say for example, a risk mitigation was to bring on more staff to a project, then those staff must be coming from a pool of people elsewhere in the organization. In other words, the wider organization is underwriting the insurance for the project. Unforeseen Uncertainty is a land of high risk – we don’t know what we know, or our system is not understood. Playing in this categorycould also be called gambling. As every gambler will tell you – you win some and you lose some. Many VC’s will tell you that they lose up to 19 for every one they win. The Unforeseen Uncertainty category is the land of venture capital. Finally, Chaos is a land where only the research budget should venture. It’s extreme gambling. It’s adventure rather than merely venture. It’s a world where you assume you lost your money and nothing got delivered. Delivery is a bonus. It’s like winning the lottery. The project management objectives for Unforeseen Uncertainty are simple – try to move the project into the Foreseen Uncertainty quadrant before the money runs out – then ask for more. With Chaos it is similar – try to move the project into either the Unforeseen Uncertainty or Foreseen Uncertainty quadrants before the money runs out. It is unreasonable to buffer a plan in the lower half of the diagram – a not understood market. It simply costs too much. Better not to buffer, but to get as far as you can with what you’ve got and demonstrate that you’ve moved to a world of greater certainty before asking for more resources. Iterative projects with adaptive planning is the name of the game.

        It’s easy to see from this chart that the more uncertain, the greater agility is needed to react to change. In the lower half, the iteration cycle must be short, the feedback loop very tight. By understanding where our project lies in this uncertainty continuum we can make decisions about what represents the best iteration cycle and make informed guesses about how much we want to invest in requirements and analysis versus code, test and refactor.

          Thoughts on DOI #3 – Uncertainty

          More explanation of the Declaration of Interdependence with the third statement focused on uncertainty.

          #3 – Uncertainty

          • We manage uncertainty through iterations, anticipation and adaptation

          The key term here is uncertainty and its scope. We had to settle on one word to capture the essence of variation, change, unknowns and chaos. We settled on uncertainty as the one single word which best captured the essence of the problem. Uncertainty in this context means from variation to chaos, as defined by De Meyer et al, Managing Project Uncertainty: from Variation to Chaos, and shown in this diagram

          By embracing uncertainty into the new paradigm, we’re clearly making a split from traditional project management theory. There is no concept of uncertainty in critical path. In the PMBOK uncertainty is handled through the notion of risk. Variation in the latest 2004 addition is handled through positive and negative risk. Positive risk? I hear you say. What the heck? Indeed!

          The DOI embraces uncertainty. It’s a reality of the universe we live in. It’s fundamental. No model of project management can deny it or go without it.

          We deal with uncertainty by iterating often, providing control and feedback points to make corrections based on the effects of uncertainty. We also anticipate uncertainty. It is the inclusion of "anticipate" in this statement which allows it to encompass Critical Chain. And finally, we learn from our feedback and adapt. This can mean adjusting future anticipation or simply reacting to current events with adaptive planning. In the new paradigm, uncertainty is a facet of planning and scheduling. Planning can be anticpatory or reactive or both. It’s not a risk management problem.

            Thoughts on DOI #2 – Customers

            Continuing my explanation of the Declaration of Interdependence with the second statement focused on customers.

            #2 – Customers

            • We deliver reliable results by engaging customers in frequent interactions and shared ownership

            We wanted to capture the idea of close partnership with customers. The term partnership tends to get misused. In the same way that executives want you to "delight customers", they often also want you to "partner" with them without fully understanding what that means. Partner means to align the supply chain’s interests and focus on the end consumer. This is how Japanese keiretsu work. It creates a mechanism to treat the whole value chain as a single system and optimize for the system not the parts.

            We also wanted to capture the quality assurance that comes from frequent customer touch and feedback.

            Together these two aspects of putting the customer’s skin in the game through (inter-)active partnership and high touch gives us a mechanism to deliver reliable results. The word reliable embraces concepts like repeatable, dependable and trustworthy without the historical baggage that the word repeatable carries in process circles.

              Thoughts on DOI #1 – Flow

              I’d like to dedicate a series of blog entries to explaining my personal take on the Declaration of Interdependence. These posts will represent my own views and not any official view from my co-signatories or the emerging organization behind the declaration.

              #1 – Flow

              The first statement in the declaration says…

              • We increase return on investment by making continuous flow of value our focus

              What this means for me is that we first need to treat projects as a flow problem. This is concomitant with Peter Drucker’s idea of a value chain. In a (software) project, the value chain creates consumer value by transforming ideas into working knowledge through a series of transformative steps. This idea was fundamental to the thesis of my book and at the time (2003) I spent rather a lot of words laboring the point in the early chapters. It seems like a much more accepted principle nowadays but back then I felt I had to do a lot of justifying to get this principle build into the management paradigm.

              So, that takes care of the latter half of the sentence but what about the first half?

              Well, the argument goes that until you embrace the idea of flow through a value chain then you cannot understand where to focus management attention and investment dollars in order to maximize the investors’ return for those dollars. Hence, adopting a flow paradigm is fundamental to devising optimal investment strategies.

              A flow model also reveals the primary role for the agile project manager – issue log management and resolution. By focusing on what is obstructing flow – issues arising – the project manager keeps things moving. The Scrum community will identify with this as the primary role of the Scrummaster. Ken Schwaber teaches quite clearly that he sees the management of the issue log, surfacing issues at daily scrums and running them down before they impact "burn down" as the primary mechanism for realizing results.

              Astute readers who are fans of TOC will realize that this first bullet also encompasses and embraces the underlying principles of TOC and the Five Focusing Steps. Once you have a flow model, you can go look for bottlenecks in the flow. More DOI and TOC when I get to the third statement about uncertainty.

              Advertisements
              This entry was posted in Computers and Internet. Bookmark the permalink.

              Leave a Reply

              Fill in your details below or click an icon to log in:

              WordPress.com Logo

              You are commenting using your WordPress.com account. Log Out / Change )

              Twitter picture

              You are commenting using your Twitter account. Log Out / Change )

              Facebook photo

              You are commenting using your Facebook account. Log Out / Change )

              Google+ photo

              You are commenting using your Google+ account. Log Out / Change )

              Connecting to %s