Tailoring Agile Practices for Enterprise System Integration Projects – Part 3

In my previous post Agile Practices in Large System Integration Projects and in Part 1 & Part 2 of “Tailoring Agile Practices for Enterprise System Integration Projects” series, I identify a set of key Agile practices that offer the greatest value and recommend ways to tailor them for large enterprise system integration projects. Examples of such systems are Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), supply chain management (SCM) and other large “packaged applications” or Commercial-of-the-shelf (COTS) system implementations.

In this post, I will discuss the controversial topic of “upfront estimates” and why agile teams can’t escape them if agile methodology is to be adopted for large system integration projects.

Many in the agile software development community believe that upfront estimation of the total cost of a project goes completely against the entire paradigm of agile.

As much as we don’t like it, organizations do want to know upfront how much a project will cost them and this becomes the basis for the decision on whether the organization should invest in the project or not. To expect organizations to change how they evaluate investments, just because we are using an agile method or agile estimating process, is not taking into account how decisions are really made in organizations.

The decision makers who usually expect “Fixed Price” are not always those involved directly with the agile project team or those directly impacted by or benefit from the outcome of the project. The pressure for upfront estimations or fixed pricing usually comes from way above in the organization hierarchy.

Traditional organizations (and most organizations for that matter) do not, or at least they are not supposed to, undertake major investments without a reasonable level of certainty upfront. They like to know upfront how much the investment will cost and what the return on the investment is expected to be. Estimates become the starting point of any conversation about funding of future investments. Time and cost estimates are the only currency these decision makers deal in, the further removed from the project they are. And, at every level of the organizations, people are measured based on how well they perform against these estimates.

Most of the senior business decision makers at the top of the management hierarchy in traditional/non-software development organizations don’t really care or want to know how the project team plans to deliver on the project outcomes.  They usually don’t even know the details of the project. They usually leave that responsibility to the Project Sponsor, who is usually the person who makes the case for the request for funding the project. These decision makers, who usually sit on various governance boards along the organization’s investment funding decision hierarchy, just want to make sure the investment is worth it for the organization at large. They want certainty because they are used to getting it when evaluating other investment options. And we can’t blame them, given all the other decisions competing for their attention their accountability for making sound investment decisions.

Unless we are talking about purely software development companies, who understand the nature of product development, I don’t expect this situation to change any time soon in traditional/non-software development companies.

Not accepting this fact, in my view, is one reason that makes agile difficult to implement in (and why it has not been warmly embraced by) large traditional organizations. To me, it is not that the philosophy behind Agile has not been understood by traditional organizations. The way I see it, agile processes must be tailored to take into account the realities (and challenge) of decision making in traditional organizations.

The sooner we come to terms with this reality, the sooner we can begin taking serious steps to adapting agile methods to tackle enterprise level projects.

In my the post, I will explore how project teams can perform high level estimation using preliminary short Fit/Gap Analysis phase.

As always, if you have any comments, questions, concerns, or rants, – or you just want to say hi – please feel free to leave a comment below. Cheers!

Please read my previous posts on this topic:

Agile Practices in Large System Integration Projects

Agile Practices in Large System Integration Projects – ERP Case Study

Tailoring Agile Practices for Enterprise System Integration Projects – Part 1

Tailoring Agile Practices for Enterprise System Integration Projects – Part 2

5 Responses to Tailoring Agile Practices for Enterprise System Integration Projects – Part 3
  1. [...] Tailoring Agile Practices for Enterprise System Integration Projects – Part 3 [...]

  2. [...] Tailoring Agile Practices for Enterprise System Integration Projects – Part 3 [...]

  3. [...] Tailoring Agile Practices for Enterprise System Integration Projects – Part 3 [...]

  4. bailiff
    April 5, 2014 | 8:20 am

    Thanks for this valuable post Lean Software Development is one of the best and famous agile techniques. focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. It also emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers.

    • samad_aidane
      April 5, 2014 | 10:06 am

      Thank you Howard for your comment. What should project management know about the role they play in Lean Software Development? Thank you again.

Leave a Reply

Wanting to leave an <em>phasis on your comment?

Trackback URL http://www.guerrillaprojectmanagement.com/tailoring-agile-practices-for-enterprise-system-integration-projects-part-3/trackback