All these thinks that are written in the book are a recompilation of years of software engineering, I’m not making this up, so yes… Software project is indeed a complex task, it is not like doing a ham sandwich, that is why it can be a big mess without the correct planning, lots of ISC’s hates to spend time planning, I do not mean that engineers don’t think that planning is not important, but they do think that is a waste of time of the project (mostly because they aren’t coding)t, and maybe doing a programming course homework doesn’t require a lot of planning, but even if you are pretty lucky, medium and large projects do require systematic approach.

# Planning is important! 

“Plan a serie of plannned small mistakes to avoid large mistakes”


Requirements development. Helps to identify in detail the problem that the team is trying to solve, it’s like the soul of the project (maybe) because the project is modeled around the requirements, architecture plans the correct solution to the problem in a high level specification, detailed design  Comprehensive plan of what is going to be build, all this together will made the project a solid work.


Checkpoint Review

“very early in the project the project team should have produced a user interface prototype, detailed requirements, and a detailed project plan”  This helps a lot to the stakeholders to know if they should invest on your project or yourself to see if it is actually posible to accomplish the goals. Maybe this tasks will take 10 or 20 percent of your project, but at the end of this you’ll have a planning checkpoint review(and see if cancelation is a positive decision), if you don’t have this, is not a crazy idea to think that there is a risk of FAILURE.


  • Good progress control is where the project progress is visible (true status of the project).
  • Binary milestones are the key of project progress management.
  • Even optimistic people need to prepare for the worst.
  • Quoting the book “if you don’t actively attack the risks on a software project, they will actively attack you.”




People is one of the most important parts of the project, so when developers find their work interesting they can achieve incredible work, productivity must come from possible goals,  and try to avoid to manipulate them or create noisy atmospheres (like in taller vertical). Not everything is the developer,the user is also a key in the project development, having the user to be involve in the project might save you from remaking the whole project if you ever find that the client did not even wanted what you make, Mockups can help you a lot, is better to involve the user early on in the project.

Rule #3 Trashing=Bad Processing

Well-defined development processes are important and necessary elements of software project survival (McConell, 1997).

McConell just said so, processes are a fundamental  in the software development, a ✌🏻good tip✌🏻 is making a schedule of the processes you’re going to do in the lifetime of the project.


Plan and fail at it, is the best way to learn to plan. At the beginning of the project you don’t know how big the project is going to be, maybe it’s going to take 5 weeks or 30 weeks, you will never know. Anyways, a good practice is to do the project in two parts, first get an idea of what you’re going to do, play around with the ideas and get a demo, in order to get approbation from the client/project owner and get a better idea of what are going to do, there is not recepe when you talk about project managing. using git is cool, if you use it in a good way, controlling the versions of your project, not by uploading everything in  a last single commit, you should better use google drive for storing in that case.


The deffiniton of working, but what you do, does not contribute to the project, if trashing is 90% of your time, then the project will not work at all, if you have a well-defined process, the software personnel can spend their work on productive stuff, and not in trashing (basically), but if you don’t have any plan, it’s going to be a hell of mistakes that will make even more mistakes that can be a critical factor in the success, processes shouldn’t be viewed as rigid steps, because when a project .



What’s wrong with that table? It’s a waste of time for a developer.captura-de-pantalla-2017-02-01-15-58-02

no advance at the beginning, it is gonna be a TOTAL FAILURE. avoid this kind of projects.



Rule #2 Test yourself

How do you know if your project is working as expected? , well, almost all skills that exist on earth can be measured with a test, it is a good way to understand your project progress. The test provided by McConell will help you to understand the shape of the project, whether is going to fail or not. it is important to be realistic and don’t lie to yourself, since is extremely important to have realistic goals, this can even help to find strengths in the project to work with.




The test is available in the next link:

Rule #1: Survive

Everybody is talking a lot about the survival training on topics related to the project management, but why? is it really so necessary to take any kind of training? you might say, “of course”, and you’ll be right, because it is good to have a direction before starting a project, it helps us to avoid losing tons of money or getting fire, it is a reality that from 300,000 software projects in the USA, between  1/3 and 2/3 of those projects will exceed their schedule and budget targets before they are delivered (McConnell, S. 1997). So yes, it is an importantopic indeed, and in software community, the users might complain a lot about the release dates and functionalities of the software, but the failure is always (or most of the times) avoidable with the right planning, anyways the manager must be in charge of the continuity of the project and prevent the cancelation from the client. This course will be like going to a camp, but, a Project Survival Training Camp. Before starting anything, the temas must follow the principal rules, or in this case, the rights (just like people, projects tent to have right and obligations too), and some rights must be satisfied in order to continue with an effective and well focus project and the rights must be required for everybody that works on the project without discrimination, having a productive environment is one of them, making everybody follow the rights will made the chances of survival bigger.



McConell, S. (1997). Software Project Survival Guide. United States: Microsoft Pres.