Mar 23 2009 10:30AM GMT
Posted by: Jaideep
Quality Assurance,
project manager,
Project Management,
recession,
Software Project,
scarcity of business,
win-win situation,
smart weapon,
software organization,
software business,
experience,
knowledge,
wisdom,
quality,
QA,
QC,
quality control,
quality manager,
product quality,
product and quality,
software team,
project team,
Project Plan,
quality issue,
product knowledge,
quality strength,
quality dependence,
thinking,
innovation,
brainstorming,
linchpin,
cornerstone,
team management,
team culture,
ascending approach,
organizational interest,
best result
Due to recession, there is scarcity of business and projects for software organizations. In such a situation, the projects in hand (and the forthcoming ones) have to be handled very carefully for a win-win situation. To attain that, there are certain smart weapons that a project manager needs to be equipped with which will not only make him and his organization a winner but would definitely have an edge over the competitors to acquire more projects. The weapons are well tested based on experience, knowledge and wisdom.
The 20 most powerful and smart weapons can be listed as:
1. Place importance on Quality
2. Be Sincere and frank in your meetings of all levels
3. Maintain and demonstrate a sense of mission
4. Work hand in hand with your peers – quality manager, development manager etc.
5. Be convinced of the trust between your product and quality
6. Let your team feel the weight of responsibility
7. Plan your course of action on all issues to avoid a crisis
8. Listened attentively to every word of your customer demonstrating great sincerity towards product and customer
9. Have strong interest in quality issues
10. Be highly knowledgeable about your product
11. Your Product and Quality (with your technological prowess and their quality strengths) must work together
12. Higher is the rate of dependence on Quality, higher is the success rate
13. To avoid major problems never leave a problem unresolved for tomorrow
14. Thinking, Innovation, Brainstorming are good tools if used regularly
15. Always have common awareness of all issues, so that your discussions are of highly substantive in nature
16. Be a linchpin (A central cohesive source of support and stability)
17. Consider customer requirements as “cornerstone” throughout the project. (The fundamental assumptions from which something is begun or developed or calculated or explained)
18. Build a culture of putting fullest sincere effort by everyone in the team(s) (vertical and horizontal).
19. Maintain a continuous gently-ascending approach (act of changing in an upward direction)
20. As a bearer of the highest level of responsibility reaffirm your determination to safeguard the organizational interest and ensure the best of the results
Mar 20 2009 10:42AM GMT
Posted by: Jaideep
team management,
software team,
project manager,
team leader,
Software Project,
Project Management
A new entrant at any level should never be burdened (leave aside “overburdened”), and an ample time should be given to him to prepare himself for the forthcoming project(s). If already there is a load of work, the minimum should fall on the new entrant, rest should be shared among the existing team members. This is to avoid any shock states for the new entrant and moreover he should be given ample time to groom, adopt, accept, learn and understand.
Simple theory is that a plant that has to turn into a tree later can not bear fruits in its plan phase. No wonder if extra burden is put on the new entrant – either he will run away, or will break down. The plant will require proper care, protection, air, water and atmosphere to grow, which becomes the responsibility of the team leader, project manager. A guideline for this should already be there in place through the top management which gets into the culture of the organization and in turn in the heart and blood of the existing team members.
Feb 20 2009 11:05AM GMT
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 16 2009 11:10AM GMT
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.
Jan 14 2009 10:10AM GMT
Posted by: Jaideep
SDLC,
business management,
Bug Management,
CRD,
Customer Requirements Document,
team management,
customer requirements
Past is not to be buried. It contains a treasure called EXPERIENCE. In software development this treasure is of ample importance for acquiring skills required to handle the unwarranted turns and twists during the development (and implementation) period.
What we can learn from the past is the hiccups that caused delays and stoppages in a development project. We can use that learning as a tool to tackle the problems occurred during the project life cycle. The learning could be in the form of:
1. Handling customer
2. Freezing customer requirements
3. Preparation of documents
4. Selection of a project manager
5. Development Team formation
6. Key users committee formation at customer end
7. Management committee formation at customer and development end
8. Team coordination
9. Tester’s involvement in the development
10. Choosing a right methodology for project management
Jan 2 2009 9:45AM GMT
Posted by: Jaideep
Project Management,
software,
software development,
developer,
tester,
project manager,
team management,
measuring effectiveness,
Project Development,
Development Manager,
timesheet,
tasksheet
In an organization engaged in software development business, timesheet is filled by all developers and testers working on any project. Timesheet a sheet of pre-formatted fields in which daily tasks performed by each person are filled in their individual sheet. The intent of timesheet varies from organization to organization. Some organizations use it for raising invoice from the customer whereas others use it to study the developers pace and engagement with the allocated work. The sheet usually comprises of person’s name, date, project name, plan for the day, and the tasks actually performed against the planned activities. It is not a complex format but it returns valuable information. It can also be termed as daily task sheet of each individual.
Filled timesheet is sent by each developer or tester to their respective leaders routinely. Besides sending it to leader, as per organization directive, a copy may be required to send to HR and/or Accounts department. The frequency may vary from daily or weekly to monthly. It may also be used by accounts person to allocate the resource (developer of tester) to the respective cost centre. In positive sense the purpose of timesheet is not to track the person but to prepare a repository to refer to immediately or later for various purposes. The purposes could be the calculation of total man hours spent on a project, the cost incurred on a project, the engagement/pace/% time of an individual in a project, backlog analysis at any stage during the development, re-allocation of task, requirement analysis etc. It becomes a good tool for HR to find out the vacation trend of an individual. HR or project leader can also schedule the trainings and vacations for each individual based on their timesheet that clearly tells their workload level.
Dec 8 2008 10:07AM GMT
Posted by: Jaideep
Project Management,
software development,
metrics,
project manager,
ChangeManagement,
project implementation,
team management,
development approach,
implementation approach,
measuring effectiveness
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?
