His blog is devoted to project management and he has original ideas about how to manage people. I think he believes that we lack some thinking and understanding for the others and this is why I feel his blog so close to my blogs PM Stories and Stop and Think!. And probably this is the reason why I like his blog so much.

Read the interview here. You may find some food for thought.

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.

You may also find these posts interesting:

• Top-down Planning – Good or Bad?
• Walking on Water
• The Most Important Rules of Delegation
• Project Management and Hiking
• The Recommended Weekly Readings (2007-08-18). Project Management

Build in Asia
Design/Review in Europe
Test in South-America
Every day.
Every 24hrs.

Well, I am starting to believe that this is a great way to speed up the process but a small devil in me asks this stupid question:

What if at some point you need to talk with the people from the previous time zone?

Suppose you found something that you don’t understand in their specification or in their code, or it seems to be wrong. You want to discuss the issue with your offshore colleagues but their working day is over and they went home. Now you have to wait until tomorrow.

I think that the time difference is a huge problem in communication and although following the sun seems to be a good idea it is not a panacea and you have to develop a strong process to ensure communication abilities without disturbing the personal life of your staff.

There is one more great article Bas wrote on offshore software development that I highly recommend: 25 Rock Solid Tips to Supervise Offshore Development. Read it and follow those tips – they are really helpful.

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.

You may also find these posts interesting:

• Recommended Readings: Computer Ergonomics
• The Recommended Weekly Readings (2007-08-18). Project Management
• How Did You Become a Project Manager – Survey Results
• Funny Computer Quotes
• How To Motivate Your Team?

First point of the author is that top-down planning is old style. He says:

Top-down planning makes the assumption that upper management has the best processes and ideas to run a project smoothly.

I think the author confuses planning with management. Top-down planning means dividing the project’s work into several big parts, then each parts is divided into smaller parts and so on until we reach small enough tasks that we can estimate and assign to somebody. Nobody said that it has to be done by the upper management although I believe that the first steps in dividing the work should be made by the project manager not because she has the best ideas but because she has the best view of “the big picture”.

The second point is that top-down planning could reinforce the “Peter Principle”

The “Peter Principle” says that individuals are promoted until they reach their level of incompetence, at which time the promotions cease. As the author explains it, people are promoted until they start doing a bad job, and then they are left in that position until retirement or until they quit.

First, this “principle” is kind of corporate humor so it doesn’t happen all the time in reality. Second, before they are promoted to the level of their incompetence, the skillful project managers are at their best position and they do their job the right way. And third, even if the PM is incompetent, they have a team of trusted people on which they can rely to make the plan together.

The same argument stays about the third point of the author: top-down planning limits buy-in from the team because the project manager wouldn’t allow them to participate in the plannig process. I will repeat: planning is not managing and it is not necessary that the project manager makes the plan by herself. Top-down planning is about how to make a plan, not about who makes it.

I am not saying that top-down approach in planning is the best way to do it but definitely it is not a wrong approach by definition. Whether it is right or wrong depends mainly on the team expertise, the technical experience they have and the knowledge about the business area.

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.

You may also find these posts interesting:

• Krishna Kumar Did An Interview With Me On Software Development
• Project Management and Hiking
• The Recommended Weekly Readings (2007-08-18). Project Management
• Project Management 3.0
• The Project Management Theories According to Bas de Baar

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

You may also find these posts interesting:

• How Can a PM Become a Real Leader?
• Software Project Management Again
• Full Time Pay for Half Time Work, Part 2
• The Two Types of Programmers
• Software For Code Reviews For Only $5! A 5-Day Offer

Rich has created his own blog recently and there you can learn more about his book-writing experiment as well as about crowdsourcing. He also wrote a post in PM Hut where you can learn more about the relationship between crowdsourcing and project management.

I found the idea of crowdsourcing intriguing and I followed some of the links he recommended. So I got into the site of Cambrian House – the home of crowdsourcing. This is a very interesting place where people share their ideas and get help and advices from the others. I am not sure if it can really bring good results as it sounds pretty much like the OpenSource idea and I am not very fond of OpenSource but I will give it a try for a little longer before I make some conclusions. You can try it by yourself – the registration is free!

Rich’s blog is called Scope Crêpe, which sounds just like scope creep – the worst project manager’s nightmare – and was intended to be funny. I put his blog immediately in my RSS reader – there are a lot of things we can learn from Rich Maltzman and with such sense of humor I believe his blog could never be boring.

Good luck Rich! I wish you a lot of grateful readers!

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

You may also find these posts interesting:

• Who Does Money Really Motivate?
• Classic Mistakes – GigaLease Case Study, Part 1
• Managing Padding in Time Estimates
• Walking on Water
• How Did You Become a Project Manager – Survey Results

You can download the book from its website – The Software Conspiracy.

Glenn Alleman of Herding Cats points our attention to the Department of Defense version of the Guide to Project Management Body of Knowledge (PMBOK® Guide). It is a better source of knowledge he says and more than this – it is free. In fact it is called “DoD Extension to PMBOK® Guide” and as they say in the preface:

The primary purpose of this document is to identify and describe defense applications of the core project management knowledge areas contained in the PMBOK® Guide, as well as those defense-intensive knowledge areas not contained in the Guide. It is important to understand that this is an extension to the PMBOK® Guide, and is not intended to be a stand-alone document.

Anyway, the document is free to download and I believe it could be useful source of knowledge to the practicing project managers.

And, at the end, a free e-book from one of the greatest software gurus – Ed Yourdon. His book Death March is still in my personal Top 10 list of all time influencing books on software development.

Craig Brown of Better Projects brought the link to the free e-book Just Enough Structured Analysis to my attention. He says:

[Yourdon] over time has migrated from a view that highly structured processes will improve project results to one where he believes the success factors are quality people and in keeping bureaucracy out of the way.

Ed Yourdon is a world class expert on software development and the book is definitely worth reading. He says in the Introduction:

This book is intended for two audiences: first, the person who is new to the field of systems analysis, and, second, the experienced systems analyst who needs to acquaint himself with systems modeling tools and techniques that have evolved over the past decade.

Happy reading!

You may also find these posts interesting:

• The Pros and Cons of Distributed Teams
• The Recommended Weekly Readings (2007-08-18). Project Management
• Walking on Water
• What Kind Of Programmer Are You?
• Project Management 3.0

I thought a long time before deciding to write something about it.

Why is it so difficult for me to write about successful products? Well, mostly because I spent most of my professional life working at project-oriented companies. Most of the projects I participated in were one-time shots and I don’t know what happened to those products – if they were ever used or if they were successful. And I can say that most of the companies operating in Bulgaria are outsourcing companies working this way. It is not their responsibility to care about the product. They only care about the current project – to be delivered on time, within the budget and within the defined scope.

I have also worked in some product-oriented companies but they were so small and so poorly managed that most of them soon bankrupted. I know about only one of them which still functions.

So it was a really big challenge to think of some example of a successful product and one of the most important questions I asked myself was “What is the definition of a successful product?” I think the only answer to this question should be “a product that makes the customer’s life easier and is used for a long time”. So, I finally decided to tell you about one of my experimental works with my own company. It is a “successful product” because it was developed almost ten years ago and is still in use and is of great help to the people who work with it.

The story started in the beginning of 1998. There was a need of a software product that calculates the debt of some companies that had taken a loan from a government agency. The problem was that the rules of calculating the interests were very complex and it was not easy to be done with common tools like a calculator or even a spreadsheet. So I wrote the program. Well, I didn’t do it alone – I had a small team of partners who comprised the development team over the years.

At the beginning it was a simple program, then the customer added more functionality, then it was branched into several product for the needs of different kinds of users, and so on. I managed all the changes to happen as different projects so I didn’t suffer a scope creep. On the contrary – it was a perfect example of well-developed developer-customer relationship.

These days a major change happened – the customer decided that a serious change in the algorithms is needed and having in mind the age of the initial product we decided that we should develop a new version using a new technology and a new architecture. So we started a new project and I am currently working on it. It is close to completion and the users are already using its beta version and are very happy because they have a good tool that helps them significantly improve their performance and saves them a lot of time.

Why it turned to be such a success? Well, I think it’s primarily because I paid a lot of attention to my customer’s worries. I was very patient to listen to them although it sometimes wasted a lot of my time but they build their trust on me and once they knew that I was the only person who understands their business they started to consider me not as a servant but as a partner and as a friend. I never had problems with sign-offs and with payments and for me the only explanation for this is the trust we build in each other. We always thought that this relationship is a win-win kind of relationship and that notion made it possible to conduct all our projects successfully and finally to get a successful product.

Unfortunately, this one of the very few examples I have of successful products. In many other cases we delivered the product to the customer and then closed the relationship with them. Building a long-term relationship based on trust and accountability is a very difficult thing and few companies succeed in that but only they later become the market leaders. I think this is the only way to succeed in the business.

I don’t want to tag other people. I read some people’s blogs on software project management but Craig has already tagged them. So I would like to invite anyone who reads my blog and has a good story of a successful software product to share it in his or her blog and to link it to this post and to Craig’s post. Good success stories are much fewer than the examples of failure so it is important for us all to know them. Just to improve our belief that success is possible – you just have to think about it!

You may also find these posts interesting:

• Project Management and Hiking
• Walking on Water
• Software Project Management Again
• The role of the Business Analyst – poll results
• How Can a PM Become a Real Leader?

The problem with risk management is the negative image of the word “risk”. [...] The tendency of most stakeholders is to jump very stressfully at the statement “this is a risk”. Therefore most of the time it’s not very easy to discuss about risks, because that’s always a conversation about problems. It’s very important the risk is not perceived as a bad thing, but as a positive attitude to make sure everyone will become a winner in the end.

Remember, risk management helps you being aware of the goals you have to achieve, and what can happen if you don’t satisfy the goals. It supports you in making the right choices!

So, have no fear of risks! In order to help you and to give you courage and self-confidence today’s recommended reading are devoted to the project risk management.

• Craig Brown of Better Projects wrote a huge series of 15 posts on project risk management. It covers almost every aspect of the risk management and it’s a great place to start learning and practicing good techniques to manage your project’s risks.
• PM Hut is another great source of high-quality knowledge about project management and there you can also find a lot of very helpful articles on risk management. I highly recommend you Creating Risk Profile Graphs by Mike Griffiths of LeadingAnswers, Project Risk Management – It’s Either Contingency Planning Now or Emergency Relief Later by Christoper J. Wright, and No Risk of Defects! Making Quality-Related Risks Actionable by Alan Koch.
• And at the end – another useful post from Bas de Baar of Project Shrink – Project Risk Checklist. The checklist is an extremely helpful tool which you can use in every project you undertake and the one Bas suggests is a very good starting point of your risk management proficiency.

Happy reading!

You may also find these posts interesting:

• The Project Management Theories According to Bas de Baar
• How would you reward your employees – cash or gift?
• The Pros and Cons of Distributed Teams
• CIO Top 100 Companies For 2008
• Follow The Sun – Tips For Offshore Development

It is worth it!

You may also find these posts interesting:

• Recommended Readings: Free e-book downloads
• Software For Code Reviews For Only $5! A 5-Day Offer
• The role of the Business Analyst – poll results
• The Most Important Rules of Delegation
• CIO Top 100 Companies For 2008

The question this month is: How do you estimate the project’s budget? My personal observations are that in the software companies in Bulgaria the project managers are not allowed to deal with the budget. The financial estimates are made by the top management and usually are kept in secret from the team, sometimes even from the project manager.

I am very curious if this practice is used elsewhere.
Please, vote! Your opinion matters!

You may also find these posts interesting:

• The Two Types of Programmers
• Techniques for Gathering Requirements
• My First Article In Quality Matters Magazine
• Top-down Planning – Good or Bad?
• Loyalty