February, 2009

Feb 27 2009   9:54AM GMT

Software Quality vs Project Quality

Posted by: Jaideep
software quality, project quality, quality standards, quality measures, quality metrics, software metrics, Project Management, Software Project, customer requirements, software product, software design, business requirements, functional requirements, software delivery, Project Delivery, project execution, project initiation, Project Development, project implementation, software strategy, test strategy, test case, Test Plan, test scenarios, test results, fixing of bugs, project close-out, post implementation phase of project

The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.

In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.

In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.

The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.

Feb 25 2009   10:02AM GMT

Top 20 End Objectives of any Software Project

Posted by: Jaideep
Software Project, software business, software project management, project objectives, business survival, growth, revenues, profits, maturity, Project Lifecycle, standards and methodology, software metrics, stakeholders, transparency, project completion, project sign-off, customer satisfaction, customer delight, customer requirements, software requirements, Team building, team role, team responsibility, team accountability, software quality, project quality, first time right, project overrun, continuous learning, Increase in revenue, Avoid revenue loss, Reduce costs, Avoid cost increases, Improved service

Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):

1. Control on Project Lifecycle

2. Standards and Methodology

3. Metrics

4. Stakeholders rights

5. Transparency

6. Pro-active approach to avoid post-mortem

7. Universal approach for similar projects

8. Timely completion, sign-offs and payments

9. Customer satisfaction and delight

10. Customer requirements and both end clarity on objectives of the product

11. Team building

12. Roles, responsibilities and accountability

13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall

14. First time right approach

15. Quality right from start – ongoing – every step

16. Increase in revenue

17. Avoid revenue loss

18. Reduce costs

19. Avoid cost increases

20. Improved service

Feb 23 2009   10:43AM GMT

Top 15 Pain Areas in a Software Project Lifecycle

Posted by: Jaideep
Software Project Lifecycle, pain areas of a software project, Software Project, customer requirements, software project management, software metrics, Methodology and Standards, documentation, Customer requirements understanding, Measurement of Overrun, Project Status review, Role clarity, Risk analysis, Team building, Project Repository, Learning from Past, Post implementation support, Quality – man, methods, approach and deliverables, Version Control

Following are the top 15 pain areas of a software project. All points listed below appear somewhere or the other in a software project lifecycle. The ratio of pain from a particular below listed item may vary from project to project within an organization, and also from organization to organization. So although the hierarchy may vary, the pain areas somehow remain the same. A lack in addressing any one of the issue listed below may call for a big hiccup in the smooth running and closure of a project. The project size (and in turn the time and team size also) will vary depending on customer and customer requirements. Although all points listed below are self explanatory, but the understanding and perception may vary from individual to individual.

In that respect, I would like to take each of the points below one by one in my forthcoming blogs to explain how much impact each of the instrument listed below will have on the project and how to overcome this pain not only for that projects but for all the projects in that organization to come in future. The most important activity for each individual is, now, to re-arrange the points (with any additions/ or replacements) according to the ratio of pain it is giving, and then learn how to convert that pain into pleasure once for all (in my future blogs for the later part!)

1. Methodology and Standards
2. Documentation
3. Customer requirements understanding
4. Measurement of Overrun is in money terms immaterial of time overrun (time is not measured in terms of money)
5. Frequent Status review in a forum
6. Status of project movement is person based
7. Role clarity to project manager and team on site
8. Risk analysis
9. Team building
10. Customer clarity in terms of milestones and payments
11. Project Repository
12. Learning from Past
13. Post implementation support
14. Quality – man, methods, approach and deliverables
15. Version Control

Feb 20 2009   11:05AM GMT

Project Manager should be like Chesley Sullenberger

Posted by: Jaideep
project manager, Project Management, Software Project, team management, Management Skills

Recently a US passenger Airbus had a serious problem just after it took off from the Airport. The plane suddenly lost power in both engines, and pilot Chesley Sullenberger judged that it would be too difficult either to return to the airport of departure or to land at a nearby airport. Instead, he decided to land on the Hudson River, which in the middle of winter was frozen over. With hardly any time to think, Sullenberger drew on all his professional experience and self-confidence and made a snap decision. His decision saved the lives of all 155 people aboard the plane. Sullenberger was the last to leave the plane, and did so only after making sure that everyone else had been rescued. He did everything he had to do right through to the end.

Some learning points can be drawn out for the project manager who is the pilot of a project. The problems and failures can be part of any project, but the project is not dead till the Project Manager raises his/her hands against those problems and failures. A good project manager will never give up till the end and apply all his inherent skills to overcome those problems and failures to make that project a success. The learning points from this incidence can be summarized as below:

Be prepared for any problem or failure.
Be Proactive
Don’t lose hope
Use your professional experience to overcome any crisis
Keep your self-confidence up always
Be ‘quick’ in taking ‘right’ decisions
Take responsibility to rescue all on board – your teams, your organization, your management, your customer and your product
Let others cheer individually on their successes/targets achieved but your cheer moment is only after the successful end of a project

Feb 18 2009   10:02AM GMT

Dear Product Manager don’t cheat your customer by bypassing final ‘testing’ of the product before launch

Posted by: Jaideep
Project Management, Software Project, SQA, QC, Quality Assurance, Software Quality Control, SQC, QA, product development, product manager

When work pressures are too high, deadlines are on head, we tend to bypass our own standards, procedures and policies. A product manager if affords to skip testing for that purpose, that means he is committing a crime which is quite serious offense. Any management supporting this idea becomes part of the crime. Testing on ‘wish’ of a person (the product manager), depending on time availability or delay in development clearly states there are no plans in reality. If development of the product is delayed, the implementation can be delayed, whatever be the pressure from customer. If customer is befooled by declaring that the product is ready to launch (which has in actual not been tested properly, and customer is unaware of this), that means the customer is being cheated.

The whole scenario calls for a delay or failure, but who cares – there is no discipline being followed and the confidence is – “we will handle any situation”. Had the product launch been delayed by clearly stating to the customer (or to the top management, if pressure if from there) that the testing and fixing of bugs will take some more days, the customer (or top management) would have always welcomed the decision and would surely have understood your compassion (and passion) towards product, organization and the customer. Definitely it is a call for troubles during launch and implementation stage if the ‘testing’ has been bypassed.

If this is so, we still are the same as we were, have learnt nothing from the past and are betting for failure in success. That also means that QA is being displayed as a ‘showpiece’ to customer or to top management.

Endnote – if you have an opinion that ‘testing’ or QC of the product is a useless activity, if you believe most of the bugs reported by the testers are useless, you are as right as your highest level commitment towards the product, development, yourself, your customer and your organization.

Feb 16 2009   11:10AM GMT

Dear Project Manager - Are your efforts in tune with your schedules (goals?)

Posted by: Jaideep
project manager, Project Management, Software Project, software development, team management, project goals, Project Plan, software

During one of my initial management trainings (years back) I learnt the different between hard worker and smart worker. This example I could never forget even after so many years. Example of a hard worker is a person who comes to office in the morning, puts off his shirt, start pushing a wall, and keeps pushing it throughout the day, keeps sweating, keeps management happy that he is working very hard, and goes off tired and weird at the end of the day with no end results. The wall is there as it is where it was in the morning.
The example of a smart worker is who comes to office, smartly dressed, hardly do any work himself, but still the results keep pouring in, the management remains happy with him.

In harsh words – there is a difference between a donkey and a horse.

Every project manager has a project charter, plan and schedule. Every project starts, but very few end in time with complete satisfaction of customer, management and project team members. Why so? Efforts are put in, in all the scenarios, but all do efforts do not fetch good results. Where lies the difference, is an important point to introspect. In most cases, even if the project fails, the project manager do not let the axe fall on him by proving n no. of reasons mostly situational and saves his skin. But at what cost and who is the loser? The management and the customer are the biggest losers in any project failure.

A project manager has to be ‘smart’ all the time to manage the project and for its successful timely completion. Major issue during a project is to be pro-active and smell the issue before it gets out of control. Second major issue is managing everything on your own, and hiding some bottlenecks from the management or customer. Infact by raising your voice and informing them about your problem related to the project will get you the solution faster and better. Taking the problem where you alone are not able to find a solution will enhance your image in their eyes. Similarly tracking your team is equally prime. Managing project is simple if your thoughts are not complex.

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.

Feb 11 2009   11:04AM GMT

Project Management – Tasks vs. Milestones

Posted by: Jaideep
Project Management, project manager, Software Project, project task, project milestone, software team, programmer, developer, technical, coder, coding, programming, Development, Project Development, project progress, project completion, PM

A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.

Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.

Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.

So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.

Milestones have more visibility as compared to tasks.

Feb 9 2009   9:55AM GMT

Mr. PM, what metrics you use for measuring “Task Completion”

Posted by: Jaideep
Software Project, Project Management, project manager, PM, project metrics, Project Status, project completion, project task, project progress, developer, programmer, coder, coding, Development, programming

It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.

Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.

Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.

Transparency about the project progress is as important as the authenticity to both – the management and the customer.

Integrity of task completed is another measure that you have to take into account for your project completion.

Feb 6 2009   10:00AM GMT

Regression Testing “has to be” rigorous – for a “good” cause!

Posted by: Jaideep
Regression Testing, testing, tester, QC, software testing, software development, software product

Regression testing comes into picture in “re-testing” of a product. The purpose is very clear – a thorough testing. Regression testing has to be as rigorous as possible, for this reason. And regression testing never happens once, it has to happen again and again till the product reaches at a maturity state of release.

The purpose of a regression testing is to manage the risks occurring after the changes done to a product. Changes happen after the bugs have been reported to the development team or if the customer has asked for changes (or a new requirement) in the developing product. In an effort to entertain them many changes are done by the developers. The changes could result in following:

A new bug developed while fixing a reported bug
A bug fixed by the developer not actually fixed
New bugs built while taking into account the new requirements or changes from the customer
Earlier fixed bug re-occurring

To handle all this, an extensive and rigorous testing is required to be done by the testers for the good cause of releasing out a “bug-free” product at the end of regression cycles.