Techniques for Gathering Requirements
I found recently an article called 10 techniques for gathering requirements. While Tom Mochal is a very competent expert and I admire his opinion a lot, some of the techniques he describes look too trivial - one-on-one interview, group interview, facilitated session - they are pretty much obvious.
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.
Filed Under Business Analysis | 2 Comments
Walking on Water
I found this great sentence, which belongs to Edward V. Berard and I am eager to share it with you:
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
Filed Under Fun, Software Development | 2 Comments
The Most Important Rules of Delegation
I found recently an article by Richard Lannon entitled 12 Rules of Delegation. While the article is fine and it really gives some insights on how to delegate I think it fails to emphasize the most critical issues of delegating responsibility to the others.
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?
Filed Under Leadership, Links, Teamwork | 8 Comments
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
The Two Types of Programmers
Jeff Atwood at Coding Horror wrote a post called The Two Types of Programmers, which gained a lot of controversial comments. Then he wrote another post trying to explain what he meant in the first one and to bring up the peace but the war has already started. I read them both. I read them many times and I still don’t understand what exactly he meant.
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!
Classic Mistakes 2008
I just received an email from Steve McConnell with the results from the last summer survey about the Classic Mistakes of the software development. I already wrote about this survey in my post Classic Mistakes Forever. Steve published his list of Classic Mistakes for the first time in 1996 in his book Rapid Development and due to the dynamic changes of the software business, last year he decided that this list need some actualization.
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
Filed Under Classic Mistakes | 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