Top-down Planning - Good or Bad?
I read recently an article in PM Hut blog by Keith Mathis where he categorizes top-down planning approach as a project management mistake. I didn’t agree with the author and I will try to put my arguments here hoping to start a discussion.
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”.
Filed Under Project Management | 5 Comments
What is the project goal?
The PMI definition of a project says that it is “a temporary endeavor undertaken to create a unique product or service” but it doesn’t say why we need to create that product or service. This definition is so often quoted and it makes the impression that the question “Why?” is not so important. Well, I believe it is.
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:
- 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?
- 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
Rich Maltzman, Crowdsourcing, and Project Management
Rich Maltzman is a certified PMP and a project manager with huge professional experience. I didn’t know him until recently I found the Fiddler on the Project Wiki where he tries (together with Ranjit Biswas, PMP) to write a book based on the principles of crowdsourcing. While I didn’t know anything about crowdsourcing either, I started looking around and I found that generally crowdsourcing is a way to create something with the significant help from the crowd. Fiddler on the Project is an experiment in using crowdsourcing to create a book on project management with the help of a hundred participants. Intriguing, isn’t it?
Filed Under Links, Project Management, Teamwork | 3 Comments
Recommended Readings: Free e-book downloads
Jeff Atwood of Codding Horror wrote an article the other day called Why Does Software Spoil? where he gave his brilliant thoughts about the feature creep that spoils all software products. I was very impressed because I also have suffered of “feature overdose” and I think I am going to add my comments soon on this topic. Continuing the theme, yesterday Jeff wrote another article, where he recommended the Mark Minasi’s e-book The Software Conspiracy. Here the author examines in great detail the “feature paradox” - new features are used to sell software, but they are also the primary reason that software spoils over time.
You can download the book from its website - The Software Conspiracy.
Filed Under Books, Business Analysis, Death March, Links, Project Management, Software Development | 2 Comments
Software Product Success Stories
Craig Brown of BetterProjects started a meme with the same title and tagged me to participate in it. He was inspired by a Scott Sehlhorst’s post at Tyner Blain.
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.
Filed Under Links, Project Management, Software Development | 6 Comments
Recommended Readings: Project Risk Management
Being a project manager means you have to deal with uncertainty. It always brings negative reactions among the project managers and their upper management. As Bas de Baar says:
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!
The Mythical Man-Month Walkthrough
TheServerSide.net started a great new initiative - classic books walkthroughs. Joseph Ottinger is the first author with a review of the first chapter of Fred Brooks’ masterpiece “The Mythical Man-Month”
It is worth it!
Filed Under Books, Project Management, Software Development | Leave a Comment
How do you estimate the project’s budget? A new poll
I just want to bring your attention to the new poll I published on the sidebar of my blog. Especially for those who are subscribed to my RSS feed and don’t visit the site.
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!
Managing Padding in Time Estimates
Estimating time is one of the most difficult and most unsure activities during the planning phase of the project management process. We had a discussion recently with some colleagues of mine about the extra time that sometimes the developers or the project managers add to their estimates, called padding.
There are two extremes about this approach. On the one side is the management’s urge to shorten the project’s duration leading to unrealistically short schedules. Sometimes the developers (usually younger and inexperienced ones) get infected by the flowing optimism and make unrealistic estimates, which you know are impossible to meet. Then, when you make the final schedule you add some percentage of time (usually between 10% and 20%) to make sure that even after the management shortens your schedule you will still have the necessary time to complete the project on time.
Filed Under Project Management, Teamwork | 3 Comments
Project Management and Hiking
Glen Alleman wrote a great post in his blog Herding Cats entitled Agile Planning. There he makes an interesting comparison between the hiking “projects” and software ones and asks serious questions to the adherents of the Agile methodologies.
He says:
Hiking requires Planning and Scheduling and Execution. Alternative plans are needed, alternative schedules always happen and alternative execution choices are always there. So what’s all the noise about Planning and Scheduling in agile software development?
And more:
Preparation is the key to a successful hike
Why wouldn’t…
Preparation be the key to success for a project?To argue otherwise - that planning, preparation, sequencing, and execution performance management - is not needed is dangerous in the hiking paradigm. Why do we think these activities are not important in the project management paradigm?
Good questions to ask ourselves and especially those religious fanatics who claim that their extreme approach with no planning is always a better solution than the traditional management methodologies.
Filed Under Project Management, Software Development | Leave a Comment
-
-
Subscribe to this blog!
-
License
The content of this site is licensed under a Creative Commons Attribution- Noncommercial- No Derivative Works 2.5 Bulgaria License -
Admin