As the time pass, the project is working well for all the teams even if Mr. T is sur that all the projects will not be deliver on time (he is still hoping for some of the projects). There is an inspection team checking every side of the proejct to see the advance in the work, and they gave some recommendations about the productivity. They want that the team enhance the productivity to deliver the final product on time. However, Mr. T explain that this strategy will make them lose a lot of time in the process. To my opinion, of course trying to improve your processes will you make lose time at the beginning, but it is really important for any project and organisation, you will gain time at the end. So, maybe the improvements have to depend of how long is your project? « The danger of standard process and not trying to do be improvement in the way you are working with your team is that you will miss changes to take important shortcuts » and that finally you will take a lot more hours to achieve your goals.
Mr. T, after this discussion tries to have more information about this question of having a better productivity. He has a discussion with Mr. Kenoros. Keneros explain him that the best way to win time and to improve the productivity it is to avoid having bugs in the programming of software. Since bugs can take 50% of the project time, it is important to avoid them. I did not really understand all the details on how it Is possible to avoid bugs on your software, they spoke about the bugs that are in the module etc. (I do not know anything about programming to Continue reading "ONLY 345 DAYS TILL D-DAY"
Chapter 13 teaches us one of the most important things in project management, especially for software products. Even though it can be extremely helpful to have guidelines and processes to follow, they should never be assumed suitable for any project. Depending on your scope and resources, tasks might be redundant or could be solved in a different way that would save lots of time for other work.
As the B and C product teams are anyways rebuilding already existing products, they all figured that specifications didn´t need to be developed from scratch but could simply be derived from the already existing software. In addition to those functional specifications, they added their own non-functional specifications suitable for the individual teams to lay the ground for their own product. However, the contrast to the A teams is huge and points to the problem that Mr. T. was aware of right from the beginning: too large teams. Instead of working on tasks that move the project forward quicker (still), the manager needs to assign unnecessary and productivity–decreasing tasks just to be able to provide one task for each team member.
It´s almost comparable to strong and weaker economies. Often, in developing or weak economies, jobs exist that industrialized countries don´t have anymore. For example, in some countries it is common at hotels for people to open doors, deliver bags to rooms, pack groceries into backs at supermarkets or help you with parking and reversing out of parking bays – and it is expected that you give those people a tip for their tasks, as for them it is their source of income. In other countries, these jobs either don´t exist or they are part