ChangeManagement

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.

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?