Ed Sullivan’s book, Under Pressure And On Time, is a no-nonsense guide for delivering software products to market in a timely manner.
In this industry where the average software project is late, over budget, or a complete failure, there are so many books written about what not to do. It’s refreshing to read a software development book that tells you “what to do” for a change.
Sullivan skips past conventional theory and provides real-world experiences and wisdom for how project managers and software development teams can succeed in this challenging industry.
Novel to Sullivan’s recommended approaches is the concept of one-team-per-project, reporting to a single manager. Conventionally, most companies split out development, quality-assurance, and product management into different departments. Sullivan describres this configuration as a model set-up-for-failure. Too many factors, he says, complicate team performance when each team-member is reporting to a separate manager.
I consult with software development companies to improve their product delivery speed and product quality. I call Sullivan’s single-team suggestion the “lean model,” and I agree with his conclusions.
In the manufacturing sciences, there is a belief that the production manager and the quality assurance manager have an inherent conflict of interest, therefore, they should be separate departments within a manufacturing organization. Many business books are written about this.
In software, however, this model is a less-effective approach. It can work, but it creates barriers between project teams for several reasons:
- Contention can arise as an “us vs them” mentality builds when team-members go back to their respective departments dougouts, to commesurate with their non-project department staff.
- As team-members need each other to succeed, it becomes easy for a team-member in one department to delay requests, or grandstand, because their department manager “has asked them to work on other things this week.”
- A department manager will tend to be uninformed about upcoming urgent project team needs and may unintentionally delay the project by asking their employee to do other things at the most inconvenient time for the project.
- A lack of focus will accompany any project team-member who has continuous department responsibilities outside of the project team.
- If contention arises, the project team-members from different departments may value disparaging another department, rather than working together to solve the problem at hand.
Sullivan goes on to discuss effective hiring techniques, retention techniques, and general healthy corporate culture factors. He talks about ranking employees in terms of inner-circle, middle-circle, and outer-circle. This reminds me of Jack Welch’s theory on differentation.
Another novel concept Sullivan describes is his simple but effective project scheduling process. He breaks each month into daily rows, listing team members names as column headers. Inside of each cell is a letter/number combination representing who needs to be finished with what task on that day. In my opinion this is much better than a gantt chart.
Sullivan goes on to describe meetings, schedule management, release management, and project closure.
I found this to be a beneficial book to read. I would recommend reading it topically, as a reference, rather than cover-to-cover.
Mike J Berry