by Donna Fitzgerald | September 13, 2016 | Comments Off on Managing a Business Agile Project: Discussing what works and what doesn’t
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 foot hold 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.
- Business agile projects focus on the delivery of a) the scope/business outcomes by b) the desired date, at c) the desired cost.
- Business agile projects have conceptually three phases to accomplish the delivering the business outcome. Envision, Build, Learn/Evaluate (thank you Jim Highsmith).
- 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
- 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.
- 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)
- All business agile projects have 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”
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.