Survival skills

Hello again!

In this post I will try to cover the most important aspects of the chapter 4 from the book “software project survival guide” by Steve McConnell. The most fundamental part of the project must be the planning, proper planning can save us a lot of time and it can be do with moderate to low effort in comparison with other parts of the project like codding of debugging. Planning comes in many forms for example:

  • Project estimates. The foundation for other project plans.
  • Revised estimates. This are created at the end of each major phase of the project for mid-course corrections.
  • Quality assurance. Technical reviews and testing assured that the project will not succumb.

The books suggest a practice I have not heard before in terms of founding and is called the two-phases funding approach in which the manager first request for the exploration phase a small sum of money and afterward the project team holds a planning checkpoint review, with this information the customer or senior manager makes a go/no go decision and then the project manager request for more founding. This technique helps a lot at the moment a person asks for a monetary estimate for the project this helps to reduce the variation down form a factor of 4 times its cost to more like plus or minus 50 percent.

Control is the second part of every administrative manual and it comes down to controlling the processes of the project and not the people, the control of a software project need to be built through active project management and it consist managing small task for different activities to not overload the charge of work and to keep an steady eye on the overall action that is taking place in development. We enforce control through visibility and visibility alone is not a simple task, to achieve this we need to make “checkpoints”, milestones and driving the software product to release state periodically so we can determine the product’s true condition while not giving away the development team, the people take a big enough importance in the development of software. Software alone is not easy to make, software requires creativity steady fingers and a sharp mind the proper team will not work well if they are not given the correct circumstances and for that we have to motivate the workers, by giving the thinking spaces, quiet rooms and appreciation. By the way I believe open offices should be non-existent. As the book clearly states.

The job of the average manager requires a shift in focus every few minutes. The job of the average software developer requires that the developer not shit focus more often that every few hours. (McConnell, 1998)

Involving users throughout the project is a critical software project survival skill, since we must remember that the product is for the customer and only he knows what he wants, unless he does not, in which case we have to discover what is that that he wants in order to create it for him. And how are we creating it ? with abstraction and only taking the most vital features for the client, most software programmers like to implement features that are hard to reach or that are overly complicated code pieces to solve a small problem in the most brilliant form we can, but that is not always the answer, we make products for the client in order for him or his company to use it and we as managers have to keep the product minimalism.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.

Brief introduction to project managent


Computer projects are scary, you involve many people, the mere existence of your project, you reputation, the reputation of your team members and many other aspects are at risk. It is one big boulder you are carrying whenever the client in question comes to you and wants to know the status of the project and with this in mind I have come to the book “software project survival guide” by Steve McConnell not because I personally know the stress that is to work for a big company and have to accommodate to the constant demand of a manager but because I come from an administration background and find a big passion for the techniques that can be applied to the existence and solvability of a computer project. I look myself as someone with a solid administrative background and the mere existence of a book so called “survival guide” intrigues me. As a former international business mayor and current student in computer science its astonish to be part of the creative process that is making software can look at this projects with a strict administrative perspective. Not so long ago I was tough in the craftsmanship that is control, projection administration, organization and control of business but to no surprise I was well far away to what was this whole process, much of what I learned can be applied to a close niche of industries and software projects are a very unique and distinguished kind of industry.

Don’t Panic

After this brief introduction, I want to summaries some of the key points in “software project survival guide”. First, and most important in my opinion is “the aspect that software projects can survive or die due to the lack of knowledge in a software team to conduct a software project, or the resolve to conduct a project effectively.” (McConnell, 1998) So many projects are not properly taken to an end because the team lacks the administrative knowledge and communication skills to carry said project. As every other project the software must be elaborated with a proper plan or guidelines to keep the project at peace and so a first. The project manager must look for the team as well for the customer and basic understanding of rules from both sides must be set, the customer wants to know what happened with the money he invested and the programmers what to feel safe for them to not lose the job.

The project as a self-sustained entity has its own needs as we can see in the next figure, we have a correlation between the Maslow hierarchy and the project one, in both cases we must first take in account the very first link and climb to at less resolve the safety needs of this entity without safety the programmers can lose focus and feel threatened to be fired, we need the people to feel as they belong in the project, and to climb the ladder to achieve personal satisfaction if we can achieve this, our project can advance and we can then look at accomplishing every task within 10 percent of its schedule and budget targets.


As seen in figure 1.2 of “Software Project Survival Guide”.

The software process

As we mention earlier proper communication between the customer and programmers must be achieved before moving on to the coding stage, the process stage draws the guidelines in which our project should be lead. Processed must be taken in to consideration before codding for many reasons and one of this reasons is to increase the project’s flexibility and efficiency. Many fallacies can be assumed during the process stage, like how it adds more work when code is needed the hasty and close of mind can agree that the most important part of the project is the coding when even most important is to stick to processed that the team can adhere to. Proper software processes make the project nimbler in the following scenarios: Quality assurance, change control, uncontrolled revisions defect tracking system integration. “An investment made in process at the beginning of the project produces larger returns later in the project” (McConnell, 1998) I take from this to never take from granted the processes of a project because they can save you lots of time in a close future and in action can be very useful in the satisfaction of the software team, custom and the project itself.



As seen in figure 1.4 of “Software Project Survival Guide”. 

Upstream, downstream

One core concept I found very interesting in the software process is the upstream and downstream, the word upstream refers to the early part of the software process such as the requirements and architecture, the “downstream” refers to the later parts such as construction and system testing. It’s a net idea, we first go upward planning the design and later on we come back from the top to do the job interesting enough is that researchers have found that an error inserted into the project stream early tends to cost 50 to 200 times as much to correct late in the project as it does to correct close to the point where it was originally put into the stream. “successful project teams create their own opportunities to correct upstream problems by conduction through, careful reviews of requirements and architecture.” (McConnell, 1998)

With this I cover Chapters1 through 3 of McConnell’s book, I hope to continue soon with the analysis of the following Chapters.


McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.