At work, I’ve been busily cranking away at deploying Atlassian Confluence to our firm’s internal users (a case study will be going up at wikipatterns.com within the next few weeks). One interesting aspect of Confluence is that Atlassian builds it using the agile development process - iterative releases every few weeks. Because of this, we’ve had to adapt our project to match the quick release cycle. We’ve diligently upgraded to almost all of the new releases Atlassian has pushed out over the course of the last year.
Overall, users love this - typically, they are used to extremely lengthy product release cycles from “Big IT” software vendors. Now, they look forward to new releases and the quicker, less disruptive evolution of the product.
Iterative project management seems so intuitive, it makes me wonder how many project managers have taken techniques like agile or scrum and applied them to non-software development projects. As a project manager, having incremental, small milestones that deliver a portion of the project’s value every few weeks seems to have several advantages - it would make projects easier to manage and monitor, and clients get to see the results of their investment quickly, and provide regular feedback into the iterative process.
Is anyone out there using these techniques for generalized project management? Has it been used this way in the past? It seems a bit counter to the highly planned and orchestrated PMBOK way of doing things.
6 responses so far ↓
1 Nate Nash // Apr 27, 2008 at 11:27 am
Excellent thoughts Jay.
Maybe the use of agile or scrum are more applicable for projects designed to achieve a goal that can be “versioned” but still wholly usable. The grand vizier of PM best practices (the PMBOK) has its history rooted in construction, defense, and engineering. While the iterative approach seems spot on for s/w, it seems to me that it might be a bit strange for something like construction.
For example, “Here’s you new office building…by the way, we couldn’t fit windows into version 1, so be careful with the rolling chairs”. Or what would the beta release of a bridge look like? You can only cross halfway?
I agree with your sentiments though. And maybe this represents a fork in the road for PM as a discipline…. Don’t manage s/w like you’re building a battleship. Conversely, “Agile Amtrak” might produce a literal train wreck.
2 Jay Hariani // Apr 27, 2008 at 12:12 pm
Thanks Nate, I was thinking less along the lines of construction and more along the lines of services projects - like iteratively building a deliverable, rather than dropping the end result of months of work on the client’s desk one day. More info on the nexus between PMBOK and Agile.
3 Dave // Apr 28, 2008 at 8:20 am
Interesting. In large construction program management, this approach may work in a different way than in s/w development. In large costruction programs, one must start with the end in mind to build the logic to get it all done on time, within budget and provide the scope required. All of the constiuent parts must be identified initially to schedule and price the work. This road map is then used to moitor and universally report progress towards the desired outcome. So starting with a blank piece of paper and improvising usually ends in disaster. It has been tried inadvertantly by some and always seems to produce the same result - chaos, additional costs and consternation followed by damage control and much blame passing.
My uneducated sense is that these tools could be quite useful in managing the program after it is established and under way. Large programs are usually a zero sum game where unforseen occurrences require agility to adjust what is happening in real time to ensure that the desired cost, scope and schedule are delivered in the end. So agility, real time reporting and effective collaboration are the keys to success in large programs. If this can help with that , it’s great.
Finally, all the buzz in design and construction management today is “Integrated Team Delivery” which brings together the owner, designer and builder on a team built on mutual trust that collaborates to get the project or program delivered successfully. Looks like a natural for wiki and all the other collaborative tools you are discussing.
4 Jay Hariani // Apr 29, 2008 at 9:49 pm
Dave, thanks for the feedback. “Integrated Team Delivery” sounds close to what we are trying to achieve in the services realm using novel collaboration tools. I think my point here is that applying a more flexible, iterative, and malleable project management methodology, combined with innovative collaboration, can achieve better end results for certain, but not all, types of projects.
5 JNash // May 1, 2008 at 4:31 pm
Interesting post, Nate. Building on Dave’s thoughts, one should be cautious of the potential for iterative project design/management to turn into “shoot from the hip” incremental management (i.e. process/project management that tackles the problem of the day/week w/o a continued focus on the long-term objective/goal of the project). With my current job, I’ve seen a number of international development projects that start out with a “let’s begin flying the airplane as we build it” approach. Many of these projects go wildly astray and fail spectacularly b/c someone (either the project designer or implementer) failed to establish a clear vision for the project, define outcomes/success early in the process, and focus their team on achieving the end goal in a timely, effective, and efficient manner. This seems to happen a lot when the organizations we work with feel rushed into starting a project for the sake of “getting shovels in the ground” as soon as possible - usually b/c of a political imperative or to justify getting additional money for the project. That said, our organization is involved with a number of projects that have managers who seem to successfully employ an agile, adaptive, iterative management style as described in your post. It is still too early to tell, but it appears, not surprisingly, that the projects that have the greatest chance of success using this approach are the ones with the strongest leaders. These leaders have been able to inspire their staff to deliver success against the goals/benchmarks (set early in the process) and are adept at navigating/responding to the needs/requests/complaints of their stakeholders w/o becoming sidetracked at every turn or getting bogged down responding to every request. So maybe it’s not so much the project management approach you use, but the leader that you at the helm and the incentives you provide the team responsible for delivering the project.
6 Justin // May 12, 2008 at 9:01 pm
There is a lot of work going on in the area of pulling together agile methodologies with the PMBOK frameworks. They aren’t quite as different as at first glance they appear. APLN is doing a fair amount of work in the Washington DC area in terms of integrating with the local PMI chapter (many Certified ScrumMasters are also PMPs - a duality which i will hopefully soon also be).
In terms of the use of such a process on a wider variety of projects, you should talk to Kevin and myself. We are using a version of agile/scrum for an enterprise planning and IT modernization effort with varying degrees of success. The overall team is over 400 people, and getting towards $100M per year - and is one of the largest attempts for agile acquisition in Government (which is not ideally suited for that type of development).
Leave a Comment