Having a good process, or trying to improve your process is always a good thing to do. But even if it’s good you have to take into consideration lots of things. This Chapter of the book The Deadline: A novel about project management talks about it in a special way.
Actually good technical workers will focus on improving your project. It doesn’t matter if you tell them to do it or not. One thing you should consider is to use formal process improvement programs. But they cost time and money, and they are not perfect at all.
In fact, during this chapter, Tompkins discovered that the awful Minister Belok stands in his way (again) and sends the MSEI to audit the programs. During the auditions of the first building, Tompkins discovered that some of his employees were using a different approach to tackle the problem, but this doesn’t please the MSEI. In fact, several employees are using similar techniques. For example, the PS-Shop-C Manager actually used Photoshop’s manual in order to establish functional requirements, but they also applied their knowledge to write the non-functional requirements. Once they ended this process they ended up with an unorthodox form, but with excellent content.
This shows that the danger of standard processes is that people will miss chances to take important shortcuts, particularly on overstaffed projects.
The Following Chapter has the most important thing I have ever read about. During this chapter, Tompkins took the decision to talk to Prospero Menotti, the Director of the MSEI. To his surprise, Dr. Menotti was very young, and during his talk, he made his petition. It has a very unfortunate event, but Dr. Menotti was unable to do what he wanted. That caused Tompkins to go to Dr. Menotti’s superior, the Morovia’s First Programmer, Aristotle Kenoros.
Aristotle was hoping to see Tompkins and agreed to do what he wanted, with a condition, he wanted a job. Tompkins gave him the job to teach the teams a thing or two that they needed. This is where the fun begins.
Kenoros proposed a technique called Last Minute Implementation. This technique consists in spend 40% or more of the project doing an elaborate, exaggeratedly detailed low-level design, and the rest of it coding. This allows you to spend less time debugging and to end faster in consequence.
The things we can rescue from this chapter is that you can get projects to perform substantially beyond the norm by making reductions in the total amount of debugging time (this can be achieved by spending more time on design). And finally, there is one last thing I really liked about this chapter, and that is that you can’t get people to do anything different without caring for them and about them. To get them to change, you have to appreciate where they’re coming from and why.
The Awesome Blog 