Planning DNA

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

---

In a previous post I have talked about the importance of having a process in a software project. And as a mention also in the post, planning is fundamental in a project for it to succeed. When we talk about planning we take in consideration many things, like: the software development plan, take estimates, review those estimates, having a quality assurance plan, etc. Planning goes beyond telling everybody what to do, how to do it and when it needs to be deliver. Planning is about checking if the project could really be made, checking risk that can appear, having control of the project.

McConnell mentions in his book that the success or failure of the project can be determine as early as the 10 percent of the way of the project. This is a very important fact for project that needs some kind of funding. For the projects that need some money to continue or to even start, McConnell proposed a two-phase funding approach. Basically, what this approach is about, is to go and find some one that can fund you for a exploratory phase, which could be the 10 percent of the project life; and after that, have a meeting to check the feasibility of the project. McConnell called this meeting: the planning checkpoint review.

Before going to the planning checkpoint review, there are some things that need to be ready so they can be shown, like:

• Vision statement.
• Business case for the software.
• Top 10 risk list.
• UI prototype.
• Detailed software development plan.

This were just some material needed before the meeting, but there are more things to add to the list. This planning checkpoint review gives three major benefits, to either the developers as to the funders. The first benefit is that the funders can take the decision of either continuing with the project or cancelling it. This is a good decision to take in that moment, because the project hasn’t demand a lot of material, so it would be a big lost for either side. The second one is that this creates a more reliable funding for the project. And the third one, is that this make the project team to focus only on upstream activities and to make them correctly.

If the project is accepted, there is going to come other factors to take in consideration, like:

• The risk management
• The project control
• The project visibility
• Peopleware
• User involvement
• Product minimalism

And of course one of the most important factors: shipping software. Each of this factors are very important to have in mind so the project can go the correct way.

Stay safe

A.C.

---

References

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

How to avoid the avoidable

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

---

When we work in a project, we are always under pressure of delivering the work on time. We are so concern that the project goes the way it’s suppose to go. We sometimes start by looking at the general plain, instead of looking at the details that compose that plain. With all this, I mean that in a software project we start by seeing only the requirements and we define other things and then we start coding right away. This is a very bad practice if you are in a medium or large project. In this example, is lacking a very important component that every project should have and that is a: process.

A process is a key factor so a project can succeed. But what do I mean when I say the word process? According to McConnell a process can have different meanings in a software project, like for example:

• Checking that the requirements are written and well-define.
• Developing a quality assurance plan.
• Making a plan on how the software is going to be develop.

Having a process in your project can bring you many benefits, however there are people that doesn’t look at it in that way. They think that making a process, is going to take away some of the precious time of the «real» tasks. By my short experience in the computer science department, I can say that I know plenty of people that think that way. That once they know the requirements, they want to start coding right away. And this people have the idea that because they are «engineers», they don’t need to plan; but they are completely wrong. Not planning in the begging can bring you A LOT of planning in the end. And believe me, is not going to be pretty.

A software project can be divided into two major parts, which are the: upstream and the downstream. The upstream make reference to the planning and design phases of a software project, while the downstream is more about the technical part of the project, like coding or testing. McConnell explains in his book, that is very difficult to solve a problem that is from the upstream, when you are already in the downstream, and this is so true. Imagine if you got the requirements wrong, that instead of developing for IOS, it was meant to be develop for android devices; and you are already in the test phase. This is a very costly modification that’s need to be made.

Remember making a process not only save you money, but also time; and not only your time, but other’s as well. Making a process is going to take you plenty of time at the begging, but at the end all that effort is going to be rewarded. 

Stay safe

A.C.

---

References

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

Starting from scratch

This post is part of a series of writings about my point of view on some chapters of the book Software Project Survival Guide by Steve McConnell.

---

«Software projects fail for one of two general reasons: the project team lacks the knowledge to conduct a software project successfully, or the project team lacks the resolve to conduct a project effectively. This book cannot do much about the lack of resolve, but it does contain much of the knowledge needed to conduct a software project successfully» (McConnell, 1998).

Since I started studying  computer science, I been part of many software projects. Some of them were small and simple, while others were a little bigger and more complex. Some of them I had to make them individually, while others I had to work with a partner or a team. The projects start to get more complicated as I am advancing in my studies. Most of the projects that I have done, have something in common: They had way to little organization. By this, I mean that I didn’t had a process to follow or a plan to make this projects. I just simply thought of how to solve the problem and I coded the solution. Most of you may think «Well you are in college, so that’s acceptable», but as I am getting closer to finish my college studies; I am starting to realize that I need to be able to make a plan for making a software project. And that’s one of the reason for reading Steve’s book, so I can get an idea of how to conduct a good software project.

«Planning close-up» flickr photo by Dan Foy https://www.flickr.com/photos/orangeacid/204163841

In his book, Steve starts talking on how this book is going to help the software community have an idea of how to manage a software project. In here, he says that this is only a model or a process that he suggest, but that you are free to follow any other processes you want, because it depends on how big or how small the project is. There are many cases in the software industry, were projects have failed because there wasn’t a plan in the beginning. It’s important to identify when a project is going into the correct path or if it is going the other way. But before starting a project is very important to take in consideration some basic notes.

McConnell uses in his book a pyramid, like the one of Maslow’s, to make a comparison of the basic needs that a software projects needs to be able to run effectively. Just as in Maslow’s pyramid, in the one of McConnell’s the lower parts of the pyramid needs to be satisfy before moving to the next level. This pyramid focus on having a good attitude and having goals as a individual in the project, but also having a good team dynamic. In any kind of project, I think that is important that every member of the team feels good and also that they feel included in the project because that is going to bust them up to keep going and deliver a good product. 

When working in a project, theres plenty of people involve. Some basic «characters» are the client, the project manager, the programmers and so on. Before starting a project, every person should know their basic rights. This rights are basically, what can they demand and what they can’t. McConnell listed some basic rights for both, the client and the project’s team. Has he says in the book this not only make the project more enjoyable, but they are a requirement to work. Imagine if there wasn’t any kind of rights that the participants involve had. It would be a total mess. It is very important that this rights are clear since the beginning of the project to all people involve.

McConnell provides in his book a test to see if your project is going in a excellent way or if it is at risk. If you are currently involve in a project and you think that is going good or even bad, you should do the test any way, to see if your thoughts are right or if you are seeing thinks in a very different way.

Stay safe

A.C. 

---

References

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