Most large enterprises struggle with project management. Software projects can be even more of a challenge because they require an interdisciplinary view that balances the perspective of technology, business, and customer. As our portfolio management office starts to mature I thought I would write a series of postings ("annals of project management") on lessons learned and lessons still being learned in our organization.
Scott Berkun's The Art of Project Management is one of the best books in the field. His "Software Planning Demystified" diagram is an "insanely simple but handy view of planning".
Berkun's diagram is an insanely simple view of planning and I will keep coming back to it in future postings. Simple ideas are powerful but they require repetition and re-enforcement if they are to stick. Using Berkun's diagram as a starting point, I will make two assertions about the software development process:
- A necessary though not sufficient condition for project success is that everyone in the organization, business and technology, should have the same understanding of how the process works: what are the boundaries of each step? what are the associated artifacts or planning documents associated with each step? who has requirements authority (i.e who is the decider); who has design authority? who has technical authority? who has budget authority?
- Projects are more than scope, schedule, and budget. They have to be navigated on a sea of constant tension and negotiation between business and technology. In complex projects the same wave can either propel a project forward or sink it entirely.