I was asked recently in a private email what I thought the connection was between Agile Project Management (APM) and the Declaration of Interdependence (DoI). Just as a reminder of the DoI:
- Increase return on investment by making continuous flow of value our focus
- Deliver reliable results by engaging customers in frequent interactions and shared ownership
- Unleash creativity and innovation by recognizing individuals are the ultimate source of value, and creating and environment where they can make a difference
- Manage uncertainty through iterations, anticipation, and adaptation
- Boost performance through group accountability for results and shared responsibility for team effectiveness
- Improve effectiveness and reliability through situational specific strategies, processes and practices.
And a quick reminder of the processes of Project Management:
and those of a large construction management firm's Project Delivery System
- Charter the team
- Plan the project
- Endorse the project
- Manage change
- Close the project
Possibly misunderstood role of project management
From my somewhat narrow view of project management, the DoI describes "best business practices" of the organizations I've managed and clients I've consulted. When I read the DoI my reaction is "... they've read the CH2M HILL Project Delivery System book" or they've read the "Successfully managing spacecraft development" handbook. Which is probably not the case of course. But one question is "how broad a set of business practices are used for the DoI?" The answer is probably irrelavent, but for me it seems the DoI is targeted at project management processes that are not working - meaning examples of "bad project management." This is an easy target, because its so obvious. Finding bad projects
At CH2M HILL there is a graded scale of project managers. Because "managing projects" is what they do for money. They do other things, but project management is at the heart of their business. "Project Completion Services" was a tag line on the local NPR station a few years ago.
I suggest there is a "misunderstanding" of the role of the project manager:
- The DoI can be seen as a general business principle approach, rather than just focused on "project management" - engage the customer, focus on value, get feedback often, enable the team to perform, create an environment for creativity. These are likely the business principles of Lockheed Martin, Target, Wendy's and I know for sure the local hardware store shares these principles, because words like these are on the wall over the cash register.
- Do PMI, DoD, DoE, NASA, or corporate trained "project managers" have the responsibility of living these principles? Probably - in some way, but where do these principles start? At large project based organizations as well as my current aerospace Program Management job, the principles described in the DoI are applied to all disciplines - not just project management. Technical, Managerial, Service, Operations, and Support. But they start with general management, senior management, or corporate officers.
- If the DoI is suggesting we change the point of responsibility then we're headed for the ditch. CobiT, SOX, Corporate governance and all that usually defines who is responsible. Alistair has made a clarifying statement about "collective responsibility" WITHIN the team. This is a good idea, but requires a stated context. The business domain is critically important here. A Flight Operations Program Officer is responsible for the safety of a mission. He can't delegate or share that responsibility. An XP development team can and should. Context, Context, Context.
These and many other Project Management topics are what interest me, at the execution level. At the principle level DoI is a general purpose statement of business process, but the action is on the ground, managing projects, producing value, satisfying customers.