Several culture shifts must be overcome to transition successfully to a modern software management process. For some of these adjustments, it will be difficult to distinguish between objective opposition and stubborn resistance. Nevertheless, there are general indications of a successful transition to a modern culture. This section discusses several of the rough indicators to look for in order to differentiate projects that have made a genuine cultural transition from projects that have only put up a facade. Many of these indicators are derived directly from the process framework described in earlier chapters; others are second-order effects.
• Lower level and mid-level managers are performers. There should be no "pure managers" in an organization or suborganization with 25 or fewer people. The need for pure managers arises only when personnel resources exceed this level. Hands-on management skills vary, but competent managers typically spend much of their time performing, especially with regard to understanding the status of the project firsthand and developing plans and estimates. Above all, the person managing an effort should plan it. This does not mean the manager should approve the plan; it means the manager should participate in developing it. In independent project assessments I have performed, a good indicator of trouble ahead is a manager who did not author the plan nor take ownership of it. The stakeholders affected by this transition are software project managers.
• Requirements and designs are fluid and tangible. The conventional process focused too much on producing documents that attempted to describe the software product and focused too little on producing tangible increments of the products themselves. Major milestones were defined solely in terms of specific documents. Development organizations for large contractual projects were driven to produce tons of paper in order to meet milestones and receive progress payments, rather than spend their energy on tasks that would have reduced risk and produced quality software. An iterative process requires actual construction of a sequence of progressively more comprehensive systems that demonstrate the architecture, enable objective requirements negotiations, validate the technical approach, and address resolution of key risks. Ideally, all stakeholders would be focused on these "real" milestones, with incremental deliveries of useful functionality rather than speculative paper descriptions of the end-item vision. The transition to a less document-driven environment will be embraced by the engineering teams; it will probably be resisted by traditional contract monitors.
• Ambitious demonstrations are encouraged. The purpose of early life-cycle demonstrations is to expose design flaws, not to put up a facade. Stake-
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.