December, 2008

The charter of a Project (or Development Manager) at the start of a new Development

The charter of a project manager or development manager at the start of a new project which requires extensive fresh development comprises of many pitfalls or showstoppers. To win over them, the project manager or development manager requires a well defined charter to adhere to.

The key points of this charter can be:
Software project management plan
Team members with their skills and job allocated
Allocation of resources – hardware & software
Schedule of execution
Cost analysis
Risk Analysis with how each one is being addressed
Technical layout and approach
A guidebook for each process
SWOT analysis
Role of any other product being embedded in this product
Role of product in the overall product line being carried by the organization
Lead the team by way of demonstration in all aspects
Define the purpose and limitations of the software development process
Sensibly tailoring or moulding the development lifecycle standards wherever required with proper documentation and justification
A chart for mapping requirement vis-à-vis the development
Embedment of statutory requirements in the software
Development and implementation in most effective and efficient manner
Trainings at all levels and stages
Measurement of progress
Change management
Customer involvement
Sign off at various stages
Review, review and review at all stages of progress

Large Project – a scare for Development (or Project) Manager – if not managed properly!

A large software development project can become scary for the development manager who is handling the project provided (s)he is lacking the experience and ability to manage people, machines, requirements and time in appropriate manner. A balanced control is the call of the time at this juncture, to give the project a right start by understanding the requirements well and selection of right people for the job. The development process needs to be planned and executed well for which a root level monitoring and control is mandatory. Having good knowledge and skills required to lead the development team goes haywired if these skills and knowledge are not executed timely and properly. The project manager or development manager has to understand the core relationship of software development with overall software product engineering, the estimated time and costs, and above all the software process being followed.

On the basis of the project requirements, the project manager has to decide upon the right life cycle model, requirements analysis, environment in which the product is to be built, control of configuration (both server and client level), development team management, and quality assurance. This is not at all easy, and can be achieved only by winning over each situation.

Software Quality – Overlooked or Underestimated – both are dangerous!

The goal of any software organization is to develop software applications in-house, or co-develop with an external agency, that meet and exceed internationally accepted quality standards. Every one knows it, that the key role in this is of QA department. With this intention, a dedicated QA department is structured in the organization, for the purpose. But most of the time, the move towards the objective mentioned above is limited or missing at all. Although the development managers too agree that in the software development business software quality is the key to their success.

In view of the above, the development managers need to revisit this area which mostly has not received all the necessary attention it deserves and which is something so crucial that the organization can ill afford to overlook.

Mostly, even if QA is in existence in the organization, it is used to test poorly designed and developed software. The reasons for this are well known, and the major one is that the QC is misconstrued to be a mere testing activity rather than looking at QC from a more holistic perspective. To this extent, the QA/QC department needs to be invited and involved at all stages of the software development lifecycle (SDLC).

To fulfill organization’s expectations and business goal in this regard, the development managers need to have a fresh discussion with QC/QA head to prepare a charter on how they plan to achieve it.

Certification in Testing is an individual goal rather than organizational goal

A Testing Certification is an individual tester’s asset rather than the organization’s asset as it increases the employment chances of the individual without apprehensively adding any substantial value to the tester’s job requirement. Definitely, the tester’s skills are enhanced (a bit) with this certification, but there is more increase in his expectations from the organization. Why a tester who is doing well at his job would go for a certification thereby compromising with his performance at job as he will be required to pay attention to studies and learning to acquire this certification. The certificate that is attracting him is for his own sake. Ofcourse, when it is an organization’s requirement to train their testers or display on board some certified testers, the initiative and drive for certification to the individual testers will start from the organization itself.

Certification is not bad. It is an exposure to a new learning. But the testers who get attracted to acquire a certificate have a different goal than a new learning or for the sake of organization. But if the intention is merely to acquire a relevant certificate for a tester, it can be examined by the organization by offering him a course relevant to his job with no certificate at the end of it. This step will display the real interest of a tester, whether he is individual oriented at this juncture or organization oriented.

Certified Tester or Experienced uncertified Tester? Whom to appoint?

At the time of recruitment of a tester, the biggest question in front of Quality Manager is to decide on certain factors related to the qualifications, certifications and experience of the candidate. The balance of all three is important. But if there is a demand to sacrifice one (or two) amongst three of these requirements, which can that/those be? Let us take them one by one in the perspective of Quality Head.

Qualification do matter, so the candidate must be having the basic IT degree (or if degree in some other stream, then that degree has to be relevant to IT, and the prospective candidate should be holding an advance IT diploma). When we are talking here of qualifications, we are talking about IT qualifications and not specific Quality/Testing related qualifications, which we would be considering in Certifications.

So, qualifications being the basic criteria, now there is a battle between the certifications or experience. Let us assume here we have three sets of resumes of the candidates. All sets have similar qualifications, and are differing on the basis of Certifications and Experience parameters. First Set of resumes is having Certified testers with no experience, so they are fresher certified testers candidates. Second set is certified testers with good experience in testing (say 2 plus years of experience). And the Third set is group of experienced testers with no certifications. Experience with this group of testers may vary from 2 to 5 years. Definitely the first set expectations in terms of salary would be lower as compared to second and third set of people, whose expectations would be almost at par.

In my view, appointing a tester with basic qualifications and some experience will be better than taking a tester with basic qualifications and certifications but less experience. Certifications, if any required, can be acquired by the tester during the job at a later stage.

When your development team is at job – don’t interrupt

When a new project lands into the hands of a project manager for development, he converts the whole project into smaller units and allocates it to different developers. Developers are divided into the groups based on the work allocated. These teams prepare their plan to develop and start working accordingly. Once the development plan is with the project manager, and the developers are tuned into development, the project manager should make least interruptions in their schedule (none unscheduled) thereby helping them in meeting their targets. Different ways in which a project manager can interrupt (which he can and should avoid) can be listed below. These are not in any hierarchy and all lines carry equal importance. The interruption points are:
1. Unscheduled review of the progress of development
2. Discussion related to any past project
3. Discussion related to any future project
4. Allocation of any other task other can the ongoing one
5. Shuffling of developers from one team to another
6. Re-allocating a developer to another project
7. Inviting a new member in a team for development load sharing
8. Approving leave to developer (unless it is too urgent or critical)
9. De-motivating even a single team member of different development team (remember – it spreads like a virus among other members)
10. Don’t forget to appreciate them at each small achievement

Mr Tester, please feel PRIDE in doing what you are doing at job

Hey my dear Tester, what you are doing is a tremendous effort in streamlining the business of your organization. It is you who understands the business requirements of your customer, learning their business rules, understanding the product built by your development team to cater to those needs, testing the product and finding the lacunae in the product, helping developers to understand those lacunae, and finally testing those fixed lacunae.

So you are playing the key role between the two extremes, the customer who is demands, and the developer, who supplies. It is important to mention here that your role is the most vital bond between the two. Infact during testing, you have to act as a dummy for customer, and examine the product as per customer’s perceptive. Now let us look at the strategy following which you can feel PRIDE in your work, and make your organization realize that. First of all testing should be a mission for you and for each of your mission, you have to be passionate. Your passionate mission every time is to find out the holes in the pot called the software product. Work with development team in collation rather than isolation and move together towards the path of reconstruction. Drive side by side rather than driving in the opposite directions. During development and testing, you and the developer have to work in a manner that if one reaches out a hand, the other clasps it. The final goal is not to pinpoint each other mistakes or shortcomings, but is to find them out and fix them to deliver a strong product to your customer and ultimately expanding your organizations business.

The product has to have the firm roots, and minimal changes, for which right understanding and development by the developers is important. You have to teach this lesson to your developers that any wounds even after complete healing will always leave scars.

Be proud of yourself, be proud of your work, and be proud of your organization… always…

Your work should speak that you are feeling PRIDE in your job, and last but not the least… make your organization PROUD of you. Testing is really a challenging job, and it is you who is doing it. Your organization already feels that you are the best resource available for this purpose.

A Tester gets unlimited learning power when he becomes inhuman

As a human being we limit ourselves in how much we learn. The learning process is initiated based on certain facts like curiosity, need of the hour, intelligence, openness and related requirements. A tester being a human being carries all the limitations of bounding himself of these facts and thus sometimes may not be able to learn completely about a product that he is going to test as a new testing project. As a human being we tend to learn only the things that we are bound or forced to learn. That bounding or force may be internal (passion, habit, urge, eagerness) or external (work requirement, business demand, customer pressure, management requirement).

A tester for that sake should, at this juncture, think of him as an inhuman, away from all these sensitivities. Then he will not be limiting himself to any boundaries as mentioned above and will be able to learn or know maximum about the software, product or project he is going to start.

After all the accuracy and coverage of testing he carries on the software or product will depend on how much he has learnt or how much knowledge he has gained about this software or product beforehand.

The same thing applies to a developer also before starting development of new software or enhancing existing software in context to understanding the customer requirements and business needs.

Being a Project Head – do you interact, interject or both?

A project head has to interact most of the time with inter and intra team members, management, customer key users, customer management and so on. Intra team members include his project leaders, project members, functional consultants, and technical leads. On intra teams front he has to continuously interact with quality head and testers. During development and implementation he has to interact with customer key users who are always interested in project development status and implementation plan. With each of these mentioned, he not only has to interact but at times (or often) he has to interject too. So a project manager has to have expertise not only in interaction but also in interjection.

Let us illustrate some situations in both the scenarios, i.e. interaction and interjection of a project manager with the various agencies (individuals or teams) in and out of organization, being part of the project. An interaction situation could be termed as a normal situation part of routine exercise. An interjection could be a situation where an abnormality has arisen out of normal routine activity and project manager’s intervention in that situation to bring the progress to the normal path.

Examples of interaction and interjection situation can be:
Interaction situations: Review of development, review of testing report, project update to own management, project update to customer management etc.
Interjection situations: Approaching customer management in case of key users interest is getting lost in the project, review of code with developer and educating him the alternative coding path being better, Alarming quality head in case testing is getting delayed or testers not performing relevant important tests.

15 checkpoints for a Project Manager at the start of a new Project

Usually at the start of a new project, a project manager has to forget the sad points of the previous projects and also to get to ground from the unusual achievements too. At this juncture a project manager is supposed to start afresh with new zeal, a new team or new members in the team, a new working, a new strategy and a new requirement. At the start of any new project and during the project, if the project manager keep track of following 15 checkpoints, he is safeguarding his project towards timely and successful completion of his project. The 15 checkpoints can be listed as below (not in hierarchical manner though):

1. What development or implementation approach are you using?
2. Are you ready for the change?
3. Are you focused on continuous improvement?
4. What metrics do you use to decide the success or failure?
5. Are you using your previous project’s measurements against current project performance?
6. Are you able to prove that your current development or implementation approach is optimized?
7. Is this proof based on objective measures or just an individual perception?
8. Are you aware of any soars in the project?
9. Are you prepared to not let those soars convert into festers?
10. Are you aware when to start measuring project performance?
11. Are you using the right metrics?
12. Do you analyze and document startup problems?
13. Do you document the learning at each step?
14. Are you improvising your practices?
15. Are you measuring effectiveness of each point listed above?