Project Head

Reference Model in Software Development – a boon for Project Manager

A reference model is a non-arbitrary model of software that is to be referred to when a new software requirement comes from a customer. The reference model will suit and fit most of the requirements given by the customer. The model is the most ideal scenario befitting the technical and functional requirements. Although the new architecture built may not (and will never) match point to point with the reference model but still it has to be as near to it as possible. Infact the reference model has to be capable to address all technical issues that may arise during the software development. During the development if a new problem is encountered, it becomes the part of reference model too. For development also the different components of the repository of the reference model are picked and absorbed wherever found suitable. So the various components are picked and fixed as it is in the software or are reworked with minor changes keeping requirements in mind.

This process not only shortens the development timeframe but also brings in more accuracy and stability in the product. It also helps the project manager to present the near to exact time and cost estimations. The reference model acts as a block of utilities or functions meant for the software being built. The best suitable blocks are selected and placed as it is. The most suitable blocks are selected and placed with a little modification. This increases the reusability as well. Reference model works as an outline sketch of the new product being developed.

50 gems to make Project Manager a real “Leader”

The main tools of a project manager are communication, partnership and guiding his/her team towards success. As long as the project is going smooth, there is no problem. But as soon as there is a crisis, it is the project manager who has to rise to the challenge and seek out the vacuum to be evacuated. Every project manager has to have something in him/her that has brought some time or the other his team out of critical situations and sailed the project successfully.

The key skills required in a project manager including those mentioned above can be summarized as below:
1. Communication
2. Partnership
3. Guide the team
4. Initiation
5. Control
6. Facilitation
7. Convergence
8. Consolidation
9. Liability
10. Right Approach
11. Ownership
12. Roles management
13. Capitalization of experience
14. Prepare for transformational technologies
15. Change Management
16. New Business Models
17. Deep understanding of methodologies and technologies
18. Drive business
19. Operate in interconnected world and global economy
20. Work together
21. Leverage each other’s knowledge and experience
22. Motivation
23. Be well organized and well equipped
24. Work with extreme ideologies in your sleeves
25. Apply innovation to traditional problem solving
26. Keep analyzing and organizing
27. Have a critical eye to assess the situation
28. Find and place most significant people in your team
29. Recognize the difference between management and leadership
30. Be visionary
31. Drive strategy
32. Market yourself and your product with full heart
33. Think Strategically
34. Do effective delegation
35. Reward performance
36. Develop individuals to their full strength
37. Be transparent
38. Build trust and relationship
39. Measure effectiveness
40. Be influential
41. Understand and overcome holes or flaws in technology you use or the product you make (before your customer finds it out for you!)
42. Don’t believe in product, get it tested by you testers extensively
43. Always believe that when developers and testers work together, with the combination of technology and strengths, the resultant product will be always better
44. Anticipate a problem and find out a solution
45. Budget
46. Provide opportunity to your developers for career development which is a key for job satisfaction, retention and succession planning
47. Be a consistent leader
48. Incorporate best practices
49. Be a role model
50. Don’t accept anything on face value. Question, examine and introspect

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.

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

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.