A "Classic" Story of Classic Mistakes by Steve McConnell
Steve McConnell wrote a great article called Building a Fort: Lessons in Software Estimation where he tells us the story how he built a fort for his children and what classic mistakes he did during this adventure. It is a brilliant lesson of how many mistakes we can make when we are put in a situation where we are not too familiar with the nature of the problem even if we are very experienced in the area of project management. Steve provides a thorough analysis of what went wrong and what were his mistakes in planning and estimating. Of course, it would be more useful for him if he had done it before he started his endeavor.
Although it’s not a software project, it’s a great example for all of us how many things we should think about and should take in consideration when making our plans and estimates. And it is always better to do this analysis in the beginning of our project instead of doing it at the end.
Filed Under Classic Mistakes, Links | 1 Comment
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 | 1 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!
Recommended Readings: Computer Ergonomics
I read recently Jeff Atwood’s post on Computer Workstation Ergonomics and I realized that I really didn’t know a lot of things that were important for my health. For the last couple of months I started working at home and I work the worst possible way – I sit in my bed holding with my laptop in my lap (this is why they called it “laptop” isn’t it?).
Unfortunately, it isn’t funny at all. My back is aching terribly and now I know the main reason for that – my bent working pose. So I did a little research and I am giving you some links to sites with very useful information about computer ergonomics and a lot of graphics and pictures.
Here they are:
- The Boston University self-help guide to computer workstation ergonomics
- Guide to Setting Up an Ergonomic Computer Station
- One more article on Computer Ergonomics
- And a whole blog devoted to ergonomics – Ergoblog
I believe this information will be of great help to you. Don’t be careless to your heath – think about it!
How Did You Become a Project Manager – Survey Results
More than a month ago I published my post How Do People Become Project Managers? about a survey performed at the Projects@Work site and I decided to ask the same questions to my readers. Only 9 people participated at my survey but the interesting thing is that their answers concur with the answers given to the Projects@Work’s survey.
Here are my questions and their answers:
1. How did you become a Project Manager?
- By accident – 7 (77%)
- By choice – 2 (22%)
2. Did you have formal PM training before your first assignment?
- No – 7 (77%)
- Yes – 2 (22%)
3. Do you like being a project manager?
- Yes – 6 (66%)
- No – 3 (33%)
The answers my readers gave bring me to the same conclusion I made in my previous post: people come to the project manager’s profession surprisingly and unprepared. Nevertheless, most of them begin to like their work and find it interesting.
I wonder what could it be if we had more training and a better promotion to our profession…
Filed Under Polls, The Role of the Project Manager | 2 Comments
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
Programmer’s Day
I was reminded today about the “unofficial” Programmer’s Day. I don’t think there will be an “official” day ever. And in fact, I don’t think anyone cares. What is more important is just to have more reasons to celebrate! And we love to celebrate! 
The logic about this day is that September 13th is the 256th day of the year and 256 is very important number for the programmer’s brotherhood. It’s a great idea but I’ve also heard about the 128th day of the year and why not celebrate the 42th day? It’s hardly possible to find a programmer who doesn’t believe in the magical nature of the number 42
Long time ago, when I was a first-year student in the University, me and my company defined another date to be the programmer’s day and it was defined with and algorithm! We announced the programmer’s day to be the first Saturday of April when it’s not the first of April (simply because it’s another holiday ). If the first Saturday happens to be on the first of April then the programmer’s day would be on the eighth of April. Why did we choose that time? Well, because then the weather becomes warmer, the spring is coming noticeably and you can go on a picnic in a fresh air. We may be programmers but we are not moles and we value the sun and the air like everyone else.
So, today is a holiday and it should be honored.
I congratulate all the colleagues working in the field of Information Technologies and everyone who feels like a programmer on The Programmer’s Day.
Happy Programmer’s Day! Cheers!
The role of the Business Analyst – poll results
I wrote a post in Bulgarian about the role of the business analyst in a software development team and I put a poll to survey how the people in the software development business in Bulgaria evaluate it. Now the poll is closed and I am giving you the results.
Question: How do you evaluate the role of the business analyst in your team?
Total votes: 27 (little but I still have few readers).
Answers:
- Very important role. The BA investigates the customer’s needs and represent them before the team – 14 votes (52%)
- All roles are equal. The BA is responsible for the functional (requirements) specification, which the developers implement – 6 votes (22%)
- We don’t need such a person. The developers do the client’s business analysis themselves – 4 votes (15%)
- What is a “business analyst”? – 3 votes (11%)
- He just hangs around here and looks silly. He cannot write a simple JavaScript – 0 votes (0%)
How to interpret the results? Obviously, the first thing that has to be noted is the small number of the votes. For me, the main reason is the fact that still very few people visit my blog and most of them weren’t impressed by the poll. I think I will open it again in the future when there will be more visitors to my blog.
Anyway, the good news is that despite the few voters, the results show that the position of the business analyst exists in the software teams nowadays and it is appreciated positively. No matter if considered as very important (answer #1) or considered equal to all the others (answer #2), the business analyst takes his/her well-deserved place in the software team (totally 20 votes for both answers, which gives around 74%)
Answer #5 is rude and represents the vulgar and arrogant attitude of some developers to the surrounding world that doesn’t write code. I am glad that nobody voted for it. It probably means that this attitude was already buried in the past.
Answer #4 is a little silly. How can you be a self-respecting developer and not know what a business analyst is? I put this answer on purpose with the intention to be chosen for fun and to make the poll more colorful. I believe that this was the intention of the three guys who voted for it. And if they really don’t know what this is – keep on reading here – there will be more posts devoted to the job of the BA.
The most interesting answer for me is answer #3. It has a double meaning. There are companies, on one hand, that work on small projects or such that work on products and don’t use project principles at all. In such companies, every developer, having been working long time on the same product and having been communicating with the field experts from the business area being automated, gradually begins to gain exactly that knowledge and experience, which make him or her a business analyst. And if you add the aspiration of the company for more exploitation of its employees we come to a natural merging of the role of the BA with the role of the software developer in one person.
However, there is another interpretation. The team (or the company) could consist only of “great programmers” – people who think they know, understand, and can do everything. It was the ideal of the past socialist society in Bulgaria – so called “multi-dimensionally developed persons” – people who believe that a developer should be skilled in every aspect of the software business and there is no need of a narrow specialization in particular areas like business analysis, project management, testing, user education, etc. The developer can do everything!
I really would like to know what were the reasons to vote for this answer. I hope some of the voters will post a comment about it. And if you have an opinion about the role of the business analyst in your team – please, share it with me. It will be useful.
Filed Under Business Analysis, Polls, Software Development, Teamwork | 2 Comments
-
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
