Many people explain that the answer to the question “Why do we do this project?” is called a project’s goal and it is very important for the project manager to stick to it and never deviate. While I agree completely that everything we do in our professional life should be done for a reason and in project management it means that we should know why we are doing that project and never forget it, I disagree with the term “project goal” because it is misleading.

There is no project goal because only living creatures have goals. A stone doesn’t have a goal so doesn’t a project. There are two parties involved in a project usually - the customer and the implementor (the project team). They have goals and their interest is written down in some form of contract.

The customer’s goal is usually a business goal - to solve some business problem, to increase the income, to decrease the expenses, to maximize profit, or to improve the company image. They believe that this goal can be achieved by creating the product or the service as a result of that project. Many people say that the project goal is the customer’s goal. But there are some questions here:

1. What if the customer assumes wrongly that the project will achieve their goal? What if you know that what the customer requests are plain stupid? (In the case of software it is usually because they give direct instructions how the product should look like without having any idea how a to develop software) What should you do if you know that in the end they are going to realize that they have spent their money for nothing?
2. What is the implementor’s goal? Is it the same as the customer’s? Isn’t it just to take the customer’s money? At least that is what we do - make software for money. Why should we care about the customer’s goals?

What do you think? I am going to share my opinion on these questions too in the future posts.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

Let you team members be creative!

(more…)

There are many occasions when a project manager is tempted to take on some development tasks especially if she is an experienced developer or when the project management activities don’t require full-time commitment. Things go worse when a technical issue arises and apparently there is no team member who can solve it. The project manager’s heart cannot restrain from plunging straight into the problem; she buries herself into that technical challenge and after that nothing can draw her attention back until a solution has been found.

This a very dangerous temptation and many former developers give in to it. The problem is that while you think about that specific technical problem you forget about all the other obligations you have as a project manager. As the old proverb says, you cannot see the forest from the trees. But your new position requires that you never lose sight of the forest.

(more…)

More interesting to me were some techniques which I find very efficient but seemingly more rarely used. So I decided to take a closer look on them and to analyze them in more details.

• Following people around (Observation). It happens very often a customer to come to us with their vision about how the new product should look like and what it should do without being able to explain what exactly is the business process running in their company or how it is going to change with the deployment of the new software solution. One of the most effective approaches to study the customer’s business process and the habits and the technical skills of the future end users is just to stay there and observe their daily activities. Observation gives us the ability to see some flaws in their work, some too complex or unnecessary activities that could be eliminated or to get some ideas to improve the process and thus to increase the customer’s profit from implementing the new software solution. It is much better if our business analysts have the ability to the actual work the users do to get a hands-on feel for the real situation.
  Unfortunately, we are often pressed by tight deadlines especially in the analysis phase (which is a big mistake!) and we rarely use this technique for gathering information.
  Sometimes, the customer doesn’t allow us to meet their employees using security arguments. In those cases we should strongly emphasize that this is a risk for the right understanding of the requirements and for the successful release of the project.

(more…)

Walking on water and developing software from a specification are easy if both are frozen.

Thanks to Irina Marudina for this piece of wisdom.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email

I started thinking and looking for some more blog posts on delegation and I came to some conclusions which I would like to share here with you.

Delegation is a two-way street, says Richard Lannon. Yes, this is an important thing that we shouldn’t forget. And when we assign a task to someone and we hold them responsible for it we have to have in mind our reasons to delegate and their reasons to accept it.

What are the issues from our perspective? There are two major questions we must ask ourselves: Why to delegate? and What to delegate?

(more…)

(more…)

He says that there are two types of programmers - Type 0 (20%) are the people who program for fun. These people live programming, they breathe programming. They use Linux and they contribute to Open Source projects. In other words (although he doesn’t say it), these are the good guys, the smart guys. The other group are Type 1 (80%) - people who practice programming for living. They work from 9 to 5, they use only Microsoft technology and they don’t read the technical news. “They are not stupid”, he says but I believe it is just what he means because the final appeal is to the smart guys to swallow their pride and to hope the stupid guys become smarter.

If you feel that you belong to the Type 1 programmers, the stupid ones, don’t worry - one of the most important characteristics of the 20% group is that they read blogs, especially Jeff’s one. So you just need to read one article of his and you’ll automatically become a member of the elite group.

Sorry Jeff, I don’t buy it!

(more…)

Now he publishes the results of this survey in a 39-page white paper along with a PowerPoint presentation. There were a lot of questions in that survey so the authors can make a deeper analysis of the nature and the origin of the biggest mistakes we make in software development. The Classic Mistakes list of 2008 has them ordered by the frequency of their occurrence and by the impact they have on the project team to deliver software on time. Mixed together these criteria give us the list of most damaging classic mistakes of our business. I will not tell you which is the most damaging Classic mistake we make - I don’t want to spoil the pleasure of reading it by yourself - just follow this link (it may require free registration) and you will know it.

My professional experience shows that most of the companies that do software development are too far away from the standards Steve has set for Rapid Development and the first and the most important step they need to make is to avoid making those Classic Mistakes. You have no chance of finishing your project on time unless you stop making such mistakes. I strongly believe that every good software project manager should have this list in front of them and should check it regularly asking themselves: Are we making Classic Mistakes? How can we avoid them?

It is not easy, of course. Sometimes you must do things classified as Classic Mistakes forced by the circumstances or by the upper management. But knowing that what you do can lead you to a big trouble will make you be more careful in your actions and to pay a better attention to the risks that are threatening you.

This white paper is a priceless source of information. Read it and think about your projects.

If you like the posts in this blog or you are interested in the discussed topics, please, subscribe to the RSS feed to guarantee yourself that you won’t miss an interesting post. You can do it in an RSS reader or by Email