I’ve recently been speaking with clients about how to handle projects in an agile environment and it occurred to me that we needed to start a much more public discussion to put a stop to the misinformation and incipient bad practices that are starting to gain a foothold in too many PMO.
I’ve been recently writing about Gartner’s concept of business agile and I think it provides the perfect frame of reference for this discussion. To kick this off I’m going to list a number of assertions so that we can collectively talk them through one by one as an interested community.
1) Business agile projects focus on the delivery of a) the scope/business outcomes by b) the desired date, at c) the desired cost.
2) Business agile projects have conceptually three phases to accomplish the delivering the business outcome. Envision, Build, Learn/Evaluate (thank you Jim Highsmith).
3) Running a business agile project is not conditioned or constrained by the choice of software development method. It would be nice if everyone was dancing to the same drummer but it isn’t a necessity
4) In a business agile project the project manager is the individual who has 51% of the decision rights and all project participants are part of a team that reports to the project manager.
5) Once individuals are assigned to a project participation is neither flexible or at their discretion. Failure of individuals to meet their commitments for anything other than personal or natural disasters will lead to replacement. (we’ll discuss politics later)
6) All business agile projects have schedules. All schedules are dependency linked. If you have a project and it really doesn’t need a schedule then it doesn’t require a project manager at which point you can feel free to manage it anyway want.
Each of these six items is worth a blog on its own so for the moment I’ll stop right here. As I said my goal is to get a discussion going so feel free to present any form of reasoned argument that conflicts with my assertions. Please note that we are talking BUSINESS AGILE here.
Obviously if there is software involved I am still asserting there is a deadline. I’m also still asserting that there is a desired cost. There are true cases of exploratory project (which we used to call Rapid Application Development) but for at least 90% of IT projects, the business outcome should be known before the project starts. Obviously there are shades of gray and politics around everything I’ve listed here but my hope is we can begin to talk it through and build a shared mental model around what will work to deliver more value faster in the “digital age”