How To Motivate Your Team?
Bas de Baar asked this question in his blog Project Shrink and asked his readers to suggest their opinions. I have always thought that having motivated people is the key to the project success but I really haven’t got “a recipe” how to motivate a software team. In fact, I know a lot of things that you can do to undermine your team’s motivation and trust, a lot of classic mistakes you can do but I didn’t have a ready answer to that question so I had to think a little deeper but I finally came up with an answer.
Let you team members be creative!
Don’t “Drill Down” Into Technical Issues
I am going to create new series in my blog called Advices to the novice project managers and I think it would be very helpful especially for software developers stepping into the project management field.
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.
Filed Under The Role of the Project Manager | 3 Comments
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 | 2 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
The Pros and Cons of Distributed Teams
I got this article recently, called 5 Reasons Distributed Teams Suck. This is an answer to another article that argues that distributed teams are great and gives us 5 reasons for that. The funny thing is that using the same arguments both authors come to different conclusions. For example:
Reason Number 5:
Pros: It saves energy. While you work at home you don’t waste time and effort for traveling.
Cons: It wastes energy. When you have to travel, you waste a lot more than if you worked in the same country and in the same office.
Where is the problem? Why these guys think so differently upon the same situation? My answer is very simple. The very definition of the “distributed team” they use is different.
When I ask myself the question “What does a distributed team mean?” I divide it into the following questions:
1. How distributed is the team? If the team works in the same town and they don’t work constantly in the office but instead they work at home I believe it really saves money and energy and this kind of distributed team works effectively because they don’t spend time traveling, they use their own computers and they only need a good internet connection to do their work (especially if the team doesn’t need any other special technical equipment). But if the team is disbursed through the globe then it might not be cost-effective at all. Especially if there are long time differences and there is a need to meet face-to-face frequently.
Filed Under Peopleware, Teamwork | Leave a Comment
Time To Say "No" And Time To Say "Yes"
We all know what monster a scope creep can become. We all know that the good project manager should know when and how to say “No” to the attempts of unnecessary scope changes that lead the project to inevitable schedule slippage. But it doesn’t mean that we should say “No” all the time to everybody.
I got involved in a project recently where the official policy of the company was to say “No” to all the customer’s requests. The project management responsibilities were shared between several people but not one of them liked to take responsibility for any decision so it became easier to all of them to say “No” instead of considering the customer’s request.
Filed Under The Role of the Project Manager | 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