• Home
  • RSS Feed
  • Log in

Reality is not plan based: change is a fact of life
Posted by Gerard Janssen in the early morning: June 22nd, 2007

The whole idea of executing a project is that you want to achieve something. A person or organization has goals that they want to achieve. A project is a way to coordinate the efforts towards achieving these goals. Ideally we set all of the goals before the start of the project, initiate the project and let it run to fulfill the goals. This way we would never have to discuss or question why we do the things we do. However, things have a tendency to change, even the goals might change. The question is how we deal with that.

understanding
There are many reasons to make a project plan. One of the most obvious is to gain a better understanding of the work that needs to be done to achieve the goals set for the project. So if you want to go from city A to city B, you plan a route to know which roads to travel on.
Equally important, although often not made explicit, is the purpose to gain a better understanding of the project goals themselves. Although these are set at the start of the project, it is not always clear what their impact is exactly or how they should be fulfilled. While planning our trip, we find out that merely stating the names of the cities we travel between is not specific enough; we need to now the exact addresses in order to plan a complete and useful route.

succes
The success of the project is measured against its goals, its objectives. This is one reason why it is important to properly understand the project goals. How often don't we see projects or people finish something, just to realize (or be confronted to) that they did not deliver what was demanded. It is like reaching the top of a mountain after a long, difficult and dangerous climb, only to realize it was the wrong mountain you climbing all along.

As stated earlier, the goals are ideally set before the start of the project. This implies that the goals have their origin, their base, outside of the project itself. This does not mean that the project cannot influence its goals. Experiences and insights gained on the project can make us see and understand the goals of the project differently.

Project goals are not fixed. The objectives for a project ought to be the result of careful deliberation and weighing pros and cons. If the paradigm on which a goal was based change, this might change the validity of that goal. Looking at reasons for changes of goals, I think there are two main sources of change: external conditions, the environment, and lessons learned within the project, the internals. These two sources are discussed below

external condition changes
During the course of a project, its environment is subject to change. These changes may be large or small and can have a big, minor of even no impact on the project. The arrival of a new competitor on the market might urge the organization to speed up the introduction of a new product, even at the expense of bigger investments. So this single event has impact on multiple goals of the project, time and money. More fundamentally it has had influence on the business case. If the new competitor would succeed in obtaining a substantial market share before the product would be released, it might become hard or next to impossible to get return on investment on the project. Thus, changes in the environment can lead to changes in the business case and to fundamental changes to project goals. In our previous example, while traveling from A to B, we might encounter a traffic jam and decide to take the alternative route to get to our destination.

internal lessons learned
When we run a project, we gain additional insight in the viability of the project goals. There is a plan that specifies what needs to be done when at what cost. However, we might learn that a chosen technology is not suitable for what is was selected for, of does not yield the productivity promised. Or we might find that communication between certain parties involved is so difficult, that more time is needed to come to mutual acceptable solution. Both of these findings have impact on the viability of the project goals. If the project needs to be done by a set date, but the involved parties can't seem to reach an agreement until late, it is not likely that original deadlines can be met.
Or in our travel example, we might discover our car has gotten a flat tire which needs to be replaced before we can continue. This certainly has an impact on our itinerary.

We have seen that on a project there is a continual influence between the project plan, its goals, external changes and internal lessons learned. In most projects, even the prescriptive ones that are led in a deterministic way, the project plan changes as the project progresses. There is however a difference between accepting changes as a basic principle of project management and changing the plan only when forced to by the circumstances. The later approach is reactive, one that in essence sees change as bad and as something to be avoided. This often leads to suboptimal choices and in which circumstances are seen as things that need to be managed and are dealt with as risks. Alternatively circumstances can be seen as opportunities. If we accept change as a necessity to keep current with reality, we can actually use it to make sure we reach a reality based result. In the end, what really matters is getting there and adapting to change is part of that.

  • Share/Bookmark

Filed under Agile, Project Management | No Comments »



No Responses to “Reality is not plan based: change is a fact of life”



Leave a Reply

Click here to cancel reply.

Deployment automation for Java application running on Websphere, WebLogic and JBoss

Archives

  • March 2010
  • February 2010
  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • August 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009

Training

  • Workshop Agile Management
    Custom made, in-company

Xebia Sites

  • Xebia Corporate
  • Xebia France
  • Xebia India

Categories

  • Java (282)
  • Agile (109)
  • General (50)
  • Testing (42)
  • Performance (42)
  • Hibernate (36)
  • Scrum (33)
  • Podcast (31)
  • Architecture (31)
  • Spring (28)
  • SOA (24)
  • Maven (22)
  • Project Management (22)
  • Middleware (23)
    • Deployment (14)
  • Flex (17)
  • JPA (17)
  • Eclipse (15)
  • Xebia Labs (15)
  • Quality Assurance (14)

Tag Cloud

    Maven Poppendieck Seam Ajax Functional Programming Lean Introduction to Agile Java Testing Spring Xebia Agile SOA Scala Grails product owner XML Groovy Closures Semantic Web qcon Agile Awareness Workshop Scrum Performance Architecture JavaOne fitnesse IntelliJ esb Hibernate