How to use Agile for Enterprise Project Planning

Door Len Gilbert op LinkedIn

Big projects with big budgets and far-off goals very often fail. Like everyone, I’ve been involved with a number of slow-moving and expensive enterprise projects that consumed thousands of hours and tens of millions of dollars while adding very little true value. The likelihood of large scale project failure has only increased in today’s digital economy thanks to the increase pace of innovative change and the disruption of business models. Oftentimes, the problem that a typical big-budget enterprise project is charged with solving changes enough during the course of the project to make the solution outdated before launch.

An Iterative Approach 

As we’ve written about before at dprism, Agile isn’t just for software. The iterative development techniques needed for software development (like a continuous release schedule incrementally adding value) reflects a software market need, and that same market need now applies to digital enterprises across all departments and functions. The digital enterprise requires nimbleness, continuous innovation, and the ability to digest as well as disseminate new information quickly. Enterprise Agile project planning aims to incorporate all those requirements and allow for adaptation.

So, how would Enterprise Agile tackle a big project with a big budget and far off goals: by working backward incrementally. Like any project, a set of results or end capabilities is decided upon, then a complete list of tasks and dependencies is listed out. Here is where the iterative Agile methodology comes into play: the project plan is elastic … including the end goal. Work is prioritized and divided into a six-week long repeating release schedule design to consistently add new value to the company. Work is also further subdivided into two-week team sprints. Every six weeks, the completed release (one building block of the larger project) is discussed and evaluated. All aspects of the project plan are then reconsidered based upon the results of the previous release, acquired developmental knowledge, and any changes in the the larger scenario. Repeating the six week cycle creates a process which gains momentum by learning from and building upon itself.

Client Example

As an example of how this can work in practice, we helped one of our clients implement Agile Enterprise to spearhead a complete digital transformation. In this case, the transformation occurred physically as well as via process change. A large room was dedicated to the Agile Enterprise team with stakeholders from Product, Technology, Marketing, Operations working side-by-side with dprism staff and other implementation specialists. All attended the daily scrum meetings and worked together on the repeating release cycles. The team has been able deliver incremental, measurable value while staying on-time and on-budget.

The common work environment broke down walls between all the groups. It encouraged the team effort and information was easily shared between individuals. The analysts/developers had easy access to business owners for clarification on requirements while stakeholders were woven into the process and had an active role in evaluating completeness of the product at various phases. The feedback allowed for errors to be caught and corrected early and gave everyone ownership of the end result. By recognizing the iterative process of agile, a product is able to be completed and released quickly. Improvements are made from feedback of actual users of the products instead of from the organization “guessing” at what the customer wants.

Transforming Work Culture

Agile Enterprise incrementally transforms work culture, encouraging stakeholder buy-in because the iterative process is more democratic. Agile project plans are not a decree passed down from on high.

Through engagements with dprism clients and our own work experience we have found that the iterative, adaptive approach of Agile Enterprise we are able to deliver the sort of large scale game-changing initiatives that used to so-often fail when attempted in waterfall fashion. Please share any thoughts you have on how this approach has worked or failed in your business!


Tags: Planning , Projectmanagement , Organisatie
Planrs maakt gebruik van cookies