Time, quality and cost
The basic of project management is a balance between time, quality and cost. Pick 2 of them. And then we start discussing about how to estimate the time when we have fixed the quality and cost (just kidding, you can pick quality and time as well).
In projects I have done over last 5 years, each always contains lots of unknown and challenges, as I have worked in most of the latest technology and sometimes I come to new project without any experience
Main problems in estimating projects can be listed as below:
– Overestimate the team competency
– Task breakdown not done carefully.
– Underestimate integration between models
– Technical unknown
– Requirement changes
This normally happens with outsourcing companies or when teams are spread between different locations. When I chat with clients or teammates, people are lazy to chat so they tend to chat short. It leads to lots of assumptions and miscommunications between people. Voice chat on skype suck energy really fast, and require both sides to communicate synchronously. It could be the miscommunication between clients and your teams or inside your team. You definitely don’t want after 3 months, you come back and the clients’ feeling is like the figure below….
Well, a famous and familiar figure huh?
Overestimate team competency
I pick my team members really hard, and I also have strong belief in my people. That is why I overestimate my team member most of the time. Belief and overestimate should be separated from each other. “Keep a cold mind and a warm heart”. That means you should keep a strong feeling in your members and encourage them to do a good work, but when evaluate them for specific project, be careful to estimate.
Task breakdown & integration
These are the 2 most underestimated when managing any projects. It is easy to look at the whole and say that it would take 3 days to finish all of them. However, if you actually break it down, and allow time for writing the code, debugging, testing and fixing bugs again,the total time could be 10 days. Oh, I forgot to mention about integrating between tasks or modules. Sometimes, we assume that if task A is done, and task B is done, combining them would be easy. Poor us, it is not usually the case. The combination between module A and module B can generate a whole new level of bugs that need fixing. The bug may only happen due to specific conditions of module A and B. It is important to run lots of tests and allocate debugging time for this phase, as shown in the following figure.
The risk level of the project depends on how many unknown stuff in your project. Some of them is that the requirement is unclear, or the technical solution is not yet known or implemented by any people in the team. It requires an expert with sharp eye to know which areas are unknown and needs to allocate time for it. The problem is people don’t know what is unknown…
One cool example that strikes me a lot is how Video Player is implemented in iOS and Android. In iOS, seeking to any arbitrary frame is a piece of cake, and I assume a well-designed framework like Android would be the same. I was totally wrong. It took me 2 months to search through many different solutions and approaches to figure how to do it in the correct way.
Only when you really get into coding, you can really know which part is challenging.
How to deal with changes
Another problem is customer change their requirement based on what you demonstrate them. An Agile approach normally helps by clearing any customers’ assumptions as soon as possible and not let them wait until the finished product. By receiving early feedback, we can constantly change the products.
1 problem of the Agile approach is that customers keep changing their minds way too often. There is 1 point that we really need to lock the requirement no matter what the customers want. Striking a balance between these issues may keep customers happy and our project budget and timeline in a good shape.