Abstract
Agile project management techniques have become one of the fastest growing and most popular aspects of IT project management. Using agile techniques in software development can make the difference between a project which has a low chance of completion and one which will deliver results very quickly and continue to deliver results over time. Yet agile thinking was never designed to be restricted to just software development. Applying this project management concept to processes and other types of projects was foreseen from the very beginning. This paper shows how you can apply the agile techniques that are used in software development to the change management process that comes with enterprise projects.
One of the key challenges in an enterprise project is the depth of change that it can cause in the organization. A common pitfall is to create a comprehensive plan and then push to deploy the entire plan at once. Applying agile thinking to change management projects is an excellent fit.
Agile project management makes us think of a project first in terms of large goals at the strategic level, and then at a tactical level has us think in terms of delivering production ready results.
The speaker, Chris Vandersluis has worked in both IT and non-IT project management for over 30 years and has appeared on numerous agile panels at project management events. He will outline an agile approach to enterprise project management.
Overview
Ahh, the enterprise project. No, not the Enterprise from Star Trek. I’m referring to projects that affect your entire organization; the entire enterprise. Enterprise projects have the capacity to make quantum improvements in an organization’s effectiveness, but they also have the potential to be very difficult to manage. In the next few pages we’ll discuss how managing enterprise projects using agile techniques more commonly found in software development projects can be advantageous.
What is an enterprise project?
An enterprise project is one which affects operations across the enterprise. Enterprise projects can be systems projects. The replacement of the organization’s finance system would certainly qualify. A finance system doesn’t just affect the accounting department. It can affect how we purchase, how we sell, how we track our clients, how we market, and how we maintain our inventory or deliver our products. But an enterprise project does not need to be about software. The move of an organization’s headquarters from one building to another would certainly qualify. A corporate merger/acquisition would certainly qualify. The creation of a project management office (PMO) would almost always qualify.
A key characteristic of an enterprise project is that it involves culture change. The project is expected to cause a change in behavior of people in the organization.
Enterprise project challenges
There are a few challenges that are so common to enterprise projects that we should mention them here.
- Enterprise projects are almost always underestimated
No matter how much detail such a project has, the complexity of an enterprise project is almost always underestimated. The very nature of the project makes that almost inevitable. When a project will cause a change in behavior, it is certain that as the project evolves, those affected will see it in with a changing perspective. Just like the old joke about asking someone for directions and getting the reply: “You can’t get there from here,” enterprise projects almost always can’t be completely evaluated until they are well underway.
As a consequence, estimates that seem perfectly reasonable prior to starting fall victim to changing views of what is really required of the system. This can have major ramifications late in the project as the schedule and budget come under pressure and, worse, the scope creeps. - The Omnibus bill mentality
In political circles, a popular vehicle for getting work done is the omnibus bill. This is a piece of legislation whose fundamental purpose is to be a bucket in which anything that needs doing can be thrown in. It often passes under the radar as politicians who know there are operational necessities that must be passed can quietly drop them into the omnibus bill.
In an enterprise project, omnibus mentality can have everyone who is affected by the enterprise project request that their pet project be included.
Moving the office? That means we’d need to move all the laptops. Wouldn’t it be great then to take this opportunity to change all the laptops then?
No, it wouldn’t.
Changing the finance system? That would mean that the delivery department will have to change its procedures. Wouldn’t it therefore be a great time to replace all our deliver trucks?
No, it wouldn’t.
Enterprise projects can take up a lot of time effort and a big percentage of the corporate budget. This makes it an obvious target for those trying to get their own projects completed.
- Whatever the problem is, it can be solved with technology
In our modern age, we have such dependencies on technology that it can be a bit too easy to think that there must be a technological answer to whatever my enterprise challenge is. Worse, if technology is involved in an enterprise project, the project can quickly become about the technology rather than the solution the project is designed to deliver.
So the change in the finance system becomes the Oracle or SAP project. The change to a centralized project management office becomes the Microsoft Project Server or Primavera or Clarity project.
It’s an easy pitfall to fall into. I have been asked numerous times: “Can you help us implement enterprise project management software?” “Why do you need it?” I always reply. Over half the time, the person doesn’t know. Articulating what our problem is and what solution the enterprise project will deliver can keep the project on track.
- Management is behind us. Aren’t they?
Maybe not. It’s common for an executive sponsor to underestimate an enterprise project’s impact. As a result, management may not understand that you will be changing corporate culture and that this may result in upset. It’s not wise to assume that management has a full understanding of how much they will be required at key moments of the project to help get personnel onboard. This can be most challenging in cultures where management by consensus is the rule. Consensus of one big happy family cheering the enterprise project as it evolves is not common. - Big Bang deployment
It’s all going to come together on a given day is one of the highest risk pitfalls of an enterprise project. The notion is that we’ll do a massive design. We’ll plan every last detail. We’ll work like hamsters on a wheel and then, at some magical time in the future, on a given day, we’ll throw a switch and the solution will turn on and start delivering results.
The more the organization is affected by the enterprise, the riskier this path is. Every day the project is incomplete, it looms on the horizon like a storm approaching for those about to affected. This puts the project at tremendous risk. Every day it progresses, something can happen to it. The sponsor can change. The company can be sold. The company can buy another company. The industry can change. The economy can change. During all of that time, the benefits from the project are just theoretical.
And, even if the wondrous day does arrive when the project is delivered, it’s a certainty that on that day someone will say: “Oh, but that’s not what we really wanted.”
That’s an enterprise project. But defining enterprise projects is not the subject of this paper.
What is agile?
The paper is about agile methodology, so it’s time we turned our attention to what agile is all about. The term agile started popular use in 2001 following the publication of something called The Manifesto for Agile Software Development. Seventeen developers met in Utah to talk about how to improve the software development process and the result was the text seen here on the right.
Yes, that is the manifesto in its entirety. It’s amazing to think of how this small amount of text has impacted the project management community. Out of these few words came standards, principles, methods, and plans for how to implement this kind of philosophy. You may have heard of one of the many iterations of agile with terms like rational or (short for the rational unified process), Scrum, extreme programming (or XP).
Exhibit 1-The Agile Manifesto1
At its essence, agile is developing the project as an iterative process rather than a pre-set plan. And that is something that was not new in 2001. To really understand agile, we should think about some of its predecessors.
Agile’s History
If we think about the period leading up to 2001 in the software industry it’s not hard to imagine some top developers generally frustrated with the kind of project management typically applied to large scale software development. In the years 1995 to 2000 the Y2K phenomena dominated the software industry. A fear that almost 50 years of software development in which date entries were represented by two characters would cause modern civilization to melt down had organizations of all sizes all over the world scrambling to change their key systems.
Organizations from the world’s largest to smallest in both the public and private sectors were all involved. Software projects for a large finance institution or a municipal, regional, or national government department could be massive, multi-year endeavors. I can remember personally visiting the project office of a multi-national bank in New York City. They gave me an example of some of the challenges they were facing: “We have, for example, one tiny piece of software which communicates from our bank to the Fed (the United States Federal Reserve Bank),” explained my host. “It transfers money back and forth based on a set of rigidly managed criteria in other systems. We know the software. It was made years ago. We know more or less what it does, but the source code for that software has long since been lost. Now imagine the challenge we have of reverse engineering that small piece of code, creating a design, writing the code anew and then testing it to make sure it works flawlessly.” She had my attention. It was a tiny project in a program full of such projects and literally thousands of people were working on this type of work inside their organization.
This wave of intense development carried through the end of the millennium and happily the world did not end. Many programs and projects were incomplete and it was not until the middle to the end of the year 2000 that many in the IT industry were able to take a deep breath and take stock.
For many, the project management style of making a design in which every bit of scope required by the enterprise that we can possibly think of is included was relegated to old style thinking that those who embrace agile call “waterfall,” referring to the way a GANTT chart might look with one task being succeeded by the next only once it is complete.
So the desire in 2001 to look at how such projects could be created and deliver results more effectively was enormous. But there were many project management examples for those 17 developers to refer to.
Rapid application design (RAD) was a precursor to agile. This philosophy was also focused on software development and became popular in the 1980s and 90s. The underlying intent of RAD was that the design did not have to be complete before work could begin. The thinking was that as the software project evolved, the participants in the project would be able to refine their design thinking as they looked at some of the software already working.
This RAD thinking extended a topic that was already well known in the engineering and construction industry called design-build.
The design-build concept became popular in the mid 1980s and early 1990s. A departure from the concept of design, then bid, then build, a design-build project was one in which a large overreaching design would be made at a high level then in more detail for early elements of the construction. As the project evolved, the designer and client would work together to refine the design’s concept and construction would follow. This has some of its roots in even earlier project management thinking called rolling wave.
Figure 1 A Rolling Wave chart circa 1987
Rolling wave planning is a personal favorite. A schedule for the project is made at a summary level, and right next to it, the immediate future of the project is planned in much more detail.
What all of these concepts have in common is the absence of a complete rigid schedule before the project starts. While that may be required for some kinds of projects, enterprise projects in particular don’t lend themselves well to rigid schedules. Nor are such schedules credible for these kinds of projects.
Does this agile stuff really work?
Yes, it can. Many IT organizations are embracing agile methodologies as a primary method of managing development projects. In most organizations we’ve encountered, a hybrid environment of more traditional scheduling and project management co-exists with agile techniques, which are more likely to be applied at the tactical level.
The most visible benefit to the organizations using this approach is the iterative release of useable functionality. The client starts to see returns from the development as each piece is completed and, as the project progresses, the depth and richness of the development increases.
A less visible but much more important aspect of these environments is that clients naturally become an integral part of the design, working with the development team more and more as the project progresses and they can see and comment on what they are receiving.
We can take advantage of this in almost any project if we apply the same kind of thinking.
We are not recommending turning your entire project management office into an agile-only environment for non-software projects. In fact, even in software-only project management offices, common project management techniques almost always co-exist with agile techniques.
Implementing agile in this way means you won’t abandon your existing project management processes, but the nature in how projects are executed can ultimately change dramatically.
Choosing what aspects of agile to apply in other contexts
Here are some of the more popular agile practices that can be applied to enterprise projects:
- Backlogs
Backlogs are the functions and features that will become a part of the final delivered project. Think of this as a large collection of scope items which have been described in terms of what they will mean to the end users. These backlog items are then assigned to resources in a small collection of work in a very short time scale called a sprint. - Sprint
A sprint is a short mini project just a few days in duration. All the tasks (backlog items) put into the sprint are expected to be completed within the sprint’s duration. What’s great about this kind of methodology in an enterprise project is that the work is tightly managed yet within the sprint itself, the team feels like they have a great deal of freedom. Also, there is structural tension within the practice to complete all your work. People tend to work hard in these environments to not be the only one of the team whose work didn’t get accomplished before the sprint ends.
And, shorter tasks are usually better managed. - Cross-functional team
The concept of cross-functional teams in agile is easily transferable to other types of projects. In some projects, teams will work in siloed departments and only come out to work with each other at designated moments. The challenge that software developers found with this is that at these designated moments, the siloed teams are dismayed to find that their work is at cross purposes with the thinking of the other teams, or that some work has been redundantly replicated by other teams. Making a cross-functional team drops the barriers between silos and the resulting inefficiency of having the different functional experts all pushed together. A cross-functional team operates with increased efficiency and has a more singular focus.far outweighed by the increased efficiency of having a more singular focus.
It is easy to imagine this kind of structure working well in an enterprise re-organization project or an enterprise corporate merger project or an enterprise office move project.
- Continuous integration
In the same way we think of cross-functional teams pulling together throughout the project, continuous integration means that elements of the project from different groups should be pulled together on an ongoing basis so that no one element of the project becomes a silo. Let’s take the example of an enterprise project to move a 1,000-person office. One group could be working on interior office furniture while another group is working on office computer networking. In traditional project management thinking, it is easy to imagine a situation where these groups only put their drawings together late in the process only to find that they have conflicts. Bringing this kind of work together while it is evolving is usually much more effective. - Information radiators
This is a great name for displays of project information and it is quite nostalgic for those of us who’ve been around project management for 30 years or more. In the 1980s, project office “war rooms” had floor to ceiling white boards, some with light blue lines painted on in a grid so that cards could be stuck to the board with magnets making network diagrams for the project. This manual process looks somewhat archaic when computer software came around but there was a wonderful aspect to having these rooms. The team congregated regularly in the room to update their project or their piece of the project and as a result, not only regularly saw other aspects of the project but also communicated with other members of the overall team. Computer-based systems caused a lot of this social interaction to evaporate and projects lost a key element of collaboration that is hard to replicate. - Iterative and incremental development
This is one of the fundamental aspects of agile that is most useful to enterprise projects of all kinds. An enterprise project is often characterized by being difficult to accurately predict in advance. Some of the scope later in the project is almost impossible to estimate before the project participants have seen the decisions and designs from earlier in the project. As a result, trying to be predictive on a massive scale is often high risk for these kinds of projects. Instead, an adaptive approach to developing early stages and returning to refine the design over and over and over can be much more effective. Returning to the concept of rolling wave planning as is described in the A Guide to the Project Management Body of Knowledge (PMBOK® Guide) has the potential to provide tremendous benefit. - Scrum meetings
Scrum meetings are meetings in which the cross functional teams meet with a facilitator (referred to as a ScrumMaster). The group updates the progress of their last sprint of tasks and regroup for the next sprint. Scope is taken from the backlog of outstanding features, tasks and issues, and assigned or adopted by members of the team who commit to what they will do in the next short period of days during the existing or upcoming sprint.
What’s great about a Scrum meeting isn’t the name which was adopted by the huddle of rugby players but the manner in which the meetings are conducted. First of all, they’re almost always blissfully quick. Since the project has been broken from an unconfrontable huge picture down into a condensed sprint, it is much easier to focus. And, finally, a standard for the facilitator is to not be a participant. That makes for a non-involved referee who can keep the project moving forward. Even the commitments people are making are for a small number of items over the next few short days. The endgame of the sprint is always within sight, even on its first day, and that has the effect of keeping the velocity of the project at a very high level.
Unlike a traditional schedule where it is easy to be lulled into thinking that it is early in the project and there is an unlimited amount of time, a sprint has you operating like the project only has a few short days to go. That type of energy is infectious and when properly guided, highly productive. - Timeboxing
Timeboxing is a term that is very familiar to those interested in traditional project management. It takes a scope of work and puts it into a schedule—a box of time. Those familiar with traditional critical path methodology scheduling will think like this by default. Those brought up in a more agile-centric project management environment will find this the exception rather than the rule. It is important however, to not abandon our traditional ways of managing projects. No matter how far you go in adopting agile practices for your non-software projects, there will always be a place to deliver on time and on budget using the techniques and practices that have become so well known in the project management industry. - Use case
An agile use case is a very commonly used method of describing what someone will do to complete a function. This technique is extremely useful in almost any process-driven project. Project managers will often have a process which is described by a title and, if lucky, a narrative, but in describing the use case, the steps to be accomplished are listed one after the other with the end result being the completion of the process. Describing a process in this way can eliminate many potential pitfalls to the projected practice. It is easy to imagine how useful this will be in a corporate re-organization or an office move or the change of any corporate process.
When this kind of technique is not employed, there is great potential for a process to be implemented only to find out a procedure on something fundamental and critical to the organization must be invented on the fly at the last minute. The potential for project delay or worse, disruption to the enterprise, could be significant. - User story
Where the use case describes a process and the steps required to complete that process, the user story is a narrative of a business problem. All too often this type of documentation is absent in a non-agile project and yet, it is critically useful. A user story outlines the very purpose of why the change is occurring in the first place. What is sadly all too common is seeing a project where the solution is being implemented without a fundamental understanding of what the problem is. In our practice, we often hear requests from clients describing a solution as though it is their problem.
“What is the business challenge or problem?” we will ask.
“The problem is, we need an enterprise project management system deployed,” the client will respond.
“No,” we’ll say. “Deploying an EPM system is the solution to something, not the problem. What is the fundamental problem?”
When you create a user story, you are describing in plain language what the problem is and how it can be overcome. This is an obvious requirement if you wish to manage that the project is complete. What could be more important to a project manager than that?
Big Bang versus Phased Approach deployments
One of the fundamental tenets of agile thinking is something we’ve promoted in enterprise project implementations for years; the benefit of a phased approach. Think of the two options:
- 1. Big Bang
Your first option is to deploy your enterprise project all at once at the very end of the project cycle. You will first be expected to make an extremely accurate prediction of what the project will have to deliver. You’ll have to assume that there will be no changes of critical corporate personnel during that time or changes in economic factors, environmental factors, industrial factors, competitive factors or anything else that could affect the project’s requirements.
Yes, that’s a tall order.
Then you’ll need to build the project targeting the end date. During this entire time, the client of the project’s change will not receive any of the benefits of the project. After all, you’re going to be deploying all at once at the end.
Finally, you’ll need to deliver the project’s benefits, assuming that everyone who was involved during the original planning process remembers perfectly what they requested, why they requested it, and that they haven’t thought of any new requests in the meantime. - 2. Phased Approach
Option 2 targets as its first phase, not the most that can be delivered, but the least: “What is the minimal scope we can deliver, the delivering of which will return a positive return on investment?” This is the question we ask when creating a phased delivery. It’s important to make sure that the first iteration is something useful and useful enough that the client won’t throw it out. The benefits of this is that the client will get value back much, much sooner even though it is only a small percentage of the final expected value.
The more hidden but critical advantage is that the client will be able to start giving feedback after only the first iteration instead of having to wait until the end of the project. The chances that there will be changes in expectation are, of course, enormous but the chances that the project will actually end up being more aligned to the client’s requirements are equally enormous.
There are, of course, advantages to each approach. The Big Bang approach is much more likely to deliver what was originally designed. That’s an advantage. The Big Bang approach also has a much higher risk of being canceled before it can deliver any value at all. That’s a disadvantage. The phased approach is much more likely to end up delivering something that is different from what was originally intended. That’s a disadvantage. The phased approach is also much more likely to be canceled once some level of diminishing returns of benefit is reached. The client can be “satisfied enough” with wherever the project has gotten to and cancel the rest. That’s a disadvantage. On the plus side, the phased approach is much more likely to deliver something that the client will be happy with and, is much more likely to deliver value since it will be delivered a bit at a time with the release of each phase.
Potential Pitfalls
We’ve talked about agile techniques and practices and how some of these practices can be applied to non-software projects. It’s probably a good time to provide some warnings of potential pitfalls to adopting agile in this way.
- Adopting everything
Just jumping on the agile bandwagon and saying you’ll adopt every aspect, technique, and practice of agile methodologies usually isn’t healthy. This is true even for software development environments. If you are instituting a corporate culture change, do it in iterative stages. Apply agile thinking to your implementation of agile techniques. You’ll need to pick and choose from those practices which are appropriate and appropriate for particular situations. - Abandoning your project management skills, thinking, and methods
Again, this is true even for software development projects. Just because there is some value here in agile techniques, should we give up on critical path schedules, risk analysis, and quality control? Absolutely not. The best case scenario for a project management office is to pick and choose from the methodologies, techniques, and practices available for given situations. - Big Bang change
Resist the temptation to make the change all at once. If you implement these techniques in a phased manner using an approach, then you will be better able to see when they are productive and should be adopted and when not.
Wrapping up
Many organizations have already started weaving agile thinking into their non-IT project management and as you’ve seen in the previous pages, you can do the same. Like any corporate culture change though, you’ll find it more effective to be discerning about what techniques to adopt and how quickly to adopt them.
There are so many sources of great information on agile techniques that it is impossible to list them all here. Wikipedia is a good starting point.
A final word
Still wondering if agile is applicable outside the software department? In a TED Talk in 2013, writer Bruce Feiler has shown that the basic agile development paradigms can be applied to household management and raising children. You can see the talk at: www.ted.com/talks/bruce_feiler_agile_programming_for_your_family.html.
