Project archives - Quality Assurance and Project Management

Quality Assurance and Project Management:

Project

Oct 30 2009   10:00AM GMT

Project Scope – Customer needs to be shown the right path



Posted by: Jaideep
Project Management, project scope, change management, project manager, software, Project, Software Project, project implementation, sign-off

One of the project managers of an ERP implementation company got himself into a tight corner. He found himself in a tough situation where an already ‘mutually sealed’ project scope asked for one or two new requirements (or changes in the existing functionality) from the client everyday while implementation. The broadly agreed upon requirements within the earmarked project modules came out with some changes here and there, some new add-ons. Customer is not ready to accept ‘no’ to any of the requirement since they have a mindset that they have ordered for a big project and are investing a large amount of money in it. The customer keeps on pushing for all their ‘now invented’ requirements to be mapped in the existing ‘project scope’. This seems to be a never ending story. The project manager is tightlipped to start a new module since the running one is not ‘done’ so far. And he also can’t say NO and mark any requirement as ‘out of scope’ since he does not want to annoy the customer and wants the project to be a success.

What should be done in this sort of scenario?

The project manager privately updated me about the situation and asked for my help to get him out of this situation. I told him if he carries out in the way he is – he will never be able to finish his project.

I advised him to have an emergency meeting with his client and share his pain with them. Make them clear that you are not saying No to their requirements but there is a need of a boundary line drawn with mutual understanding. Cater to so far documented requirements as phase I. Finish it off. Get it signed off. Whatever new requirement or changes come from the customer – document it, analyze it. Any requirement that is asking for more than 4 hours of efforts, put it in phase II of the project. As soon as you finish off the phase I, finish off Phase II, sign off. And so on.

Oct 28 2009   10:00AM GMT

Eighteen commandants for Project Management Meetings



Posted by: Jaideep
Project Management, Project, Software Project, project team, project meeting

18. All meetings related to the project must be fruitful for its continuous progress and timely actions.
17. Duration of the meetings should be optimum to cover all major concerns and immediate actions required.
16. Meetings should bring all participants close to break the barrier between them.
15. Don’t hesitate to have one-to-one talk where important.
14. Have lively discussions.
13. Have concrete progress.
12. Explain after taking time the points that require proper knowledge to be brought to all the members.
11. Propose your views and action points.
10. Stress on your viewpoints where you feel the importance need to be expressed to the members.
9. Commit full co-operation
8. Understand every member’s viewpoints
7. Participate in complete
6. Focus on each member and their suggestions
5. Strip away the mental wall separating the members
4. Strengthen the mutual cooperative relationship towards the common goal
3. Give sincere response to the issues
2. Restore trust
1. Make it overall a meaningful meeting


Oct 19 2009   10:00AM GMT

How to predict the number of bugs in the next code of a programmer



Posted by: Jaideep
code, coding, programmer, programming, tester, testing, Project, Project Management, Software Project, Bug, bug report

You have a programmer who is writing codes for years that comes to you for testing. The programmer might be coding for a number of projects simultaneously or sequentially. Similar would be the case with you. You would be testing a number of projects simultaneously or one after the other. By now your subconscious mind knows the pattern of bug writing while coding by each of the programmer. But since these patterns are not recorded or analyzed you can not predict the probable number of bugs in the next set of a code from a programmer.

You can do that with the help of your bug reports so far you have submitted back to the programmer or development team. Just pull out your last ten bugs reports produced from the code written by the same programmer. Check for a specific number of lines of code how many bugs were found. Based on this one report’s bugs were from how many lines of code. Do the same exercise for all other reports. Take an average for all ten reports.

Based on the number of lines of code, this way you can easily predict the number of bugs that will be there in the fresh set of code submitted by the programmer for testing.


Oct 16 2009   10:00AM GMT

Five Tips for a project manager for driving (and completing) a Project successfully



Posted by: Jaideep
project manager, Project Management, Software Project, project team, software, Project

Involve all stakeholders throughout: This does not mean that all people involved in the project have to keep them available full-time during the project but it means that the knowledge about the project, project progress, shortcomings, bottlenecks etc. should be continuously shared across the board universally. All members should have the same set of information available with them at any moment of time. Involvement will definitely vary from person to person and phase to phase.

Collaborative, Participative, and Interactive: The information flow should not be one way. It should comprise of praises, shouts, appreciations, arguments etc. Let each brain contribute in making it a success.

Be Demonstrative: Lead the project. Demonstrate by actions what you want from other members. Use fewer words and more actions, especially in case of crisis or a problem.


Identify the lazy goat:
If there is any lazy goat that is bound to spoil the show, indentify it at an earlier stage so as to avoid higher risk at a later stage.


Keep a set of your customer shoes with you:
Borrow a set of your customer shoes, and keep it with you during the project. Put off your shoes frequently, wear your customer shoes and then have a look at the project pace, progress and status. It will definitely give you a different perspective view.


Aug 12 2009   10:00AM GMT

Seven Questions on ‘Average Cycle Time’ of your projects?



Posted by: Jaideep
Project, Software Project, Project Lifecycle, project phase, project execution

What is cycle time?
Cycle time in terms of a software project is the time taken from its initiation to handover. Another measure in terms of commercials could be order to execution to recovery… A project lifecycle in other terms

Do you measure it?
You might be banking on your experience without any data in place!

What is your definition of project cycle time?
In your opinion it might be what I said above. It might be nothing for you! Or might be some other definition!!

Is it merely based on gut feeling and past experience?
If you are not recording the development of a project from one stage to another, your cycle time measurement sheet could be a blank sheet.

What is objective measurement?
As we all know each project has several phases. Each phase is divided in milestones. One measure could be the time taken by each milestone from it planning to completion. There would be certain parallel activities. On the other hand some activities could be incremental in nature. Measure accordingly.

Do you segregate your similar type of projects?
You might be running different types of projects. Some could be similar to each other and may fall in one category. Another set of projects could make another category.

Do you know average game is successful for similar types?
An average cycle time worked out for similar set of projects falling in one category will work best for you for your future estimations and meeting those estimations. Else average may not work well and estimations may go haywired.


Feb 13 2009   11:06AM GMT

Dear Project Manager – your “faith” in 5 pillars of project can get you miraculous success in any Project



Posted by: Jaideep
Project, Project Management, project manager, software, customer, management, team, process

I remember a small inspirational story read somewhere recently. A small girl took all the money she had in her piggy bank and went to a nearby drug store. The drug store owner was busy on a phone, and the girl was waiting for him to get free at the earliest. As she got desperate she interrupted the owner – “excuse me – I want to buy miracle, how much it costs?”. The owner kept on talking over the phone with giving an ear to her. She repeated the same again, this time in a raised tone. Owner told her as he is busy talking to his brother staying in a far country after a long time. The little girl literally had tears, helpless as if she wanted something urgently. Another man was standing inside the shop. He got curious by what the girl had asked for. He asked the girl – “what do you want?”. She said I want miracle, and I have money for it. “But what do you need it for” – the man asked her. “My brother is very seriously ill, and my mother says only a miracle can save her” – she replied. The man was the most senior neuro-surgeon of the country. He accompanied the girl by saying – ok, I have the miracle, let us go to your house to see your brother. The boy was operated free of cost and got well. The total cost of operation was “FAITH” of the little girl and some dollars she had in her piggy.

Like the little girl, the project manager has to have this tool with him all the time to win over any situation and to gain success in any project. The 5 pillars of the project where a PM has to put his total faith into are:

5. Customer: The customer is the on whose money your organization, management, your teams, and you exist. Your faith in customer has to reflect in all your discussions, communications, deliveries and product. Chose your words very carefully when you are in front of your customer or even when you are having an off-hand communication through phone conversations, emails etc. Your actions speak louder than your words. So take care of your gestures and bod language too.

4. Management: Your management is banking on you for the building and delivery of the product. Don’t mingle facts with over-enthusiastic assumptions when you present the project report to your management or to your customer. Be realistic and conservative in presenting the facts and projections.

3. Team: Don’t divide your team into doers and non-doers, slow and fast runners, perfect and imperfect. Labels regarding the individuals once set in your mind will drastically and adversely affect the project. Trust them in the same volume as you want them to trust you.

2. Processes: Whatever processes and procedures you adopt for project management, follow them ethically, trust them and they will deliver you the best.

1. Self: This is the prime factor. If you don’t have this, if you don’t trust yourself, you will not be able to adhere to the 4 points mentioned above. You can (deliver your best) only if you think you can.

Miracles do happen but only buying coin is TRUST.