March, 2009

Mar 30 2009   9:50AM GMT

A good programmer is not always useful

Posted by: Jaideep
Software programmer, project manager, Software Project, software skills, quality program, software programming, software development

Once upon a time there was a programmer, a very good programmer. Good here means skilled, learned, experienced, and serious. He was appointed by an organization for a large project for a job to write quality programs. He was doing it well and was able to prove his point that he is good for the purpose he has been appointed for.

All of a sudden the large project was required to be closed. Now, the good programmer had to be absorbed in some other project, as company was in favor or retaining him. He was moved to another project requiring different platform development skills. The development platform is different than the one on which he was working in the previous project. He was master of this platform also and assured the management that he is fit for this new requirement and would be able to deliver well as he was (in his earlier project).

But somehow, his new project manager started feeling that – he needs lot of spoon feeding, he is not very productive and is quite slow in delivery, he is not self driven, he is not enthusiastic enough and does not report well.

Would someone like to share – who needs to do what in this case?

Mar 26 2009   10:22AM GMT

Hello Project Manager - Hare and Tortoise – a Classic case to tackle

Posted by: Jaideep
project manager, project team, project organization, Software Project, software team, Organization culture, Organizational discipline, HARE, TORTOISE

Let me start with the classic story –
This refers to the team of a Project Manager. The team size may vary from project to project and organization to organization, but the story remains the same. Story is quite short and interesting. A Project manager assigns different set of tasks to his team on 5 members individually. Each member has to start the work on Monday morning and finish it off by Friday evening. One member finishes her all assigned tasks on Thursday evening (without compromising with the quality of work), goes to her project manager, reports about the completion of task and requests for an off on Friday with a genuine reason. The project manager refuses although he admits that the work is complete, it is quality work, and the reason for seeking off is also genuine. The reasons for not sanctioning her the day off given by him were – it will spoil the culture and discipline and it may lead to non-quality work production. He was more into favor of her sitting with other team members and helping them in finishing off their individual tasks.

Well said, but this is only one side of the coin. Although project manager trusts all team members but out of fear he is not ready to do a favor to one member as it may spell out wrong signals for others.

But has the project manager understood that there are always HARE and TORTOISE in a team. All have just one responsibility – finish their task in assigned timeframe and produce quality work. It is not HARE’s responsibility to help others. If HARE is able to finish off her tasks earlier than stipulated time, it is a credit and she deserves a reward for that. And above all what about her trust getting hurt and she getting demotivated by not getting a reasonable favor.

I am sure, the reader would have their individual opinion on this – would love to hear!!

Mar 23 2009   10:30AM GMT

20 most powerful and Smart weapons for Project Manager to Lead in Recession Period

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

How to manage new entrant in a project team

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.

Mar 18 2009   10:37AM GMT

Don’t create panic when team momentum is at bottom of the graph

Posted by: Jaideep
Team momentum, Software Project, software team, implementation phase, Project Initiation phase, Project Management

Usually during the period between first project close-out and next project initiation, most of the team members of project have not much to perform except utilizing their time in non-visible activities. This could include personal web browsing, social sites, pending emails, thinking about improvisations, learning from past etc.

In an organization, management has to understand that if some of the teams of team members are sitting idle that does not mean they are useless. That means that they are undergoing revitalization phase. Surprisingly you will notice that by allowing teams/members to sleep at job when not at the peak of a project will generate an extra bounce of energy which can be utilized at the time when they jump into a project, especially when on a remote site during implementation phase. During this phase most of the team members don’t bother about time and pay their full energy into completion of project in as best possible manner as they can. And probably that energy, zeal and feeling comes from that period when they are allowed to relax.

Mar 16 2009   11:07AM GMT

A wonderful powerhouse gifted to a project manager – his Team

Posted by: Jaideep
project manager, project team project leader, module leader, functional consultant, technical consultant, Database architectures, Project Management, system designer, developer, programmer, tester, team performance

All project managers depend on their teams working on the project and in turn the persons who form the team. Teams could comprise of project leader, module leaders, functional consultants, technical consultants, database architecture, system designers, developers, programmers, testers etc. To keep working towards excellence a project manager has to focus continuously on people management, grooming of teams and team members.

If project manager’s has this as one of the top priority in his list then his performance, the results related to his project, and his team’s momentum are always improving. The top management and the project manager have to clearly understand that what it makes to run a company and project successfully is not anything else but the people constituting various teams.

Mar 13 2009   10:07AM GMT

7 mandates for Customer Organization on Software Project “Ownership”

Posted by: Jaideep
1. Software Project Ownership, Software Project, specifications finalization, implementation, project manager, Key users, requirement freezing, implementation phase, UAT, project close-out, project milestones, Project Management, Project Plan, business practices, Business Rules, statutory requirements, project initiation

In software project there are two key agencies involved – customer and vendor. Both have to own equal responsibility in managing, monitoring and completing it successfully. In my earlier blog I have mentioned 6 mandates for Vendor Organization on Software Project Ownership. Here I would like to highlight 7 mandates for Customer Organization on OWNERSHIP in a software project. If both these mandates are followed, there is not doubt about the success of a project.

Mandates can be as below:
1. Involvement of top management during specifications finalization and implementation is mandatory: Most of the times customer management thinks their role only in signing off the project initiation documents and after that they feel it is the responsibility of the vendor team and their organization team managed by respective project managers to run the show and make it a success. This is a wrong concept, as the top management has to play a lead role in defining their expectations and requirements during specifications finalization phase of the project. They have to keep monitoring the progress of the project in later stages too. Generally what happens is that the top management do not define their requirements and expectations during this phase and at the final stage of implementation they feel robbed off as they realise that they are getting nothing or something they did not require or expect.

2. Project Manager and Key users should be identified well in advance and should be spared from all other responsibilities during requirement freezing and implementation phase: The top management should identify the project manager and key user well in advance based on their business knowledge, process ownership and commitment towards the organization. They should also ensure that this team’s top priority is now this project where they have to define specifications of requirements, UAT, implementation, reconciliations etc. And if they are engaged in their day to day routine activity or in any other critical program, they would not be able to do the full justification to the project.

3. Management has to ensure all milestone sign-offs – like requirements study, UAT, Implementation close-out etc: The management has to ensure that they mutually identify the milestones of the project. Proper sign off after each milestone achieved, monitoring of milestones progress etc. The persons understanding the gravity and seriousness of the matter should be authorized for signing off the various stages.

4. Project Manager has to ensure about the specifications completeness and validation during requirement freezing phase. Also he has to ensure his own and the key users’ availability during the project implementation, training and UAT phase: The project manager chosen by the top management has to ensure that accurate and complete requirements being documented validated by respective process owners. Since top management can not be involved in day to day activities of the project, he, being the project manager has to raise an alarm to the top management as and when he foresees any deviation from the plan or unavailability of key persons of his team who have to define the requirements or have to vet the validity of software meeting those requirements defined.

5. Project manager has to ensure the adherence of implementation plan timeline and any non-adherence has to be escalated well in time: As said above, Project manager has to be very careful and serious in this regard, and should be empowered enough to raise the appropriate alarm to the right person at right time at any level.

6. Top management has to review the progress of the project regularly as per schedule (weekly/daily): Top management has to have a process to monitor the progress of the project. The metrics could be plan vs actual or anything. Their involvement in monitoring the progress will definitely keep everyone in the team on their toes.

7. Persons dedicated for requirement freezing should be well aware of business practices, processes and statutory requirements of their organization and country: This is very important but not critically analyzed often. The persons identified for defining the process, requirements and business rules should be well aware of the business practices and processes of their organization and any statutory requirement of their country.

Mar 11 2009   10:15AM GMT

6 mandates for Supplier Organization on Software Project Ownership

Posted by: Jaideep
1. Software Supplier Organization, Software Project Ownership, Software Project, software development, Project Lifecycle, project monitoring, project manager, Project Initiation phase, roles and responsibilities

Ownership is a big issue in a software project. Customer organization assumes that since they are spending money, it is the sole responsibility of supplying organization to make the project a success. Vendor organization on the other hand assumes otherwise. Who is right? I think both are wrong at their ends. A Project can never become a success while the two agencies involved act as separate islands. Both have to take the equal ownership to make it a success.

The six important mandates that a vendor organization should follow in that regards can be listed as below:
1. Involvement of top management is mandatory: Involvement of top management of the organization engaged in development of software product for an external customer has to be involved in the complete project lifecycle to make it a success. This does not mean a day-to-day involvement in monitoring the progress but there should be some metrics to monitor the overall progress at any moment of time. Another aspect is involvement of top management gives a serious impact on the progress of the project.

2. A dedicated project manager should be nominated for the complete project lifecycle: Right at the Project Initiation phase, a dedicated project manager needs to be assigned for the project. The selection of project manager should be very carefully done, keeping in mind that not only he should be expert in managing a project but he should have ample business knowledge also related to the project he is being assigned to manage.

3. Role of project manager and team has to be well defined at the start of a project: The roles and responsibilities are important to be defined well in advance to clear any ambiguities and to smoothen the progress path.

4. The project manager will act as a consultant to the customer regarding project plan and its adherence: It is the sole responsibility of customer project manager (and in turn their top management) regarding availability of customer project manager and key users in various stages of the project as agreed upon. Project Manager and the supplying organization have to act as a consultant. The responsibility to gear up the progress falls on the customer team. Vendor team can help them in support and educate them on how to achieve it.

5. The management has to ensure that the project manager and the team chosen for the customization/ development have to have enough business knowledge (of their respective domain) apart from technical skills: As mentioned above regarding the project manager, the same holds truth for developers, and testers too. Without reasonable business knowledge, even the expert developers and testers will not able to do the full justification to the product being built/ developed.

6. Project Manager has to ensure during the project lifecycle that the person who is signing off the requirements, UAT, and other stages from customer end is authorized person from customer management to do so: Many a times it happens that in a very busy scenario or with some other top priorities in hand, the customer management instead of releasing appropriate person for the relevant job, ask some junior person to do so which creates lot of issues.

Mar 9 2009   10:28AM GMT

20 points for organizational self evaluation to check where it stands in Software Project Management

Posted by: Jaideep
1. organizational self evaluation, software project management, Project Management Methodology, project metrics, customer expectations, organizational goals, continuous improvement, software development, software testing, software bug, product release, process integration, project management evaluation checklist, customer feedback, customer request, innovation process, software implementation, project implementation, post implementation, project manager, project team, roles and responsibilities, on-site project, off-site project, project overrun, Risk analysis, Risk Plan, empowerment, Code repository, test case repository

1. Does a formal Project Management Methodology exist in your organization?
2. Are you using some metrics to check if this is the right methodology?
3. What is the degree of improvement required in your current methodology to meet your customer expectations?
4. What are your organization’s primary and secondary goals?
5. Do you agree that there is always a scope for continuous improvement in everything we do – be it process, method or skills?
6. Do you agree that a product developed without any pre-defined procedure has varying chances of success?
7. Do you have a culture of performing development and testing as separate activities?
8. Do you assure a bug-free product at the time of its release?
9. Do you see all your processes integrated going hand in hand?
10. Do you get your payments from customer in time?
11. Do you have a process to capture customer feedback and request?
12. Do you have an innovation process in place?
13. Do you have a post implementation review in place?
14. Are your project managers and their teams aware of their roles and responsibilities – on-site and off-site?
15. Do you have project overruns often?
16. Do you have a risk analysis and planning process in place?
17. Are your employees delighted in doing whatever they are asked for?
18. Do you have empowerment process in place?
19. Are you certain about success in your projects or is it by chance/ by luck?
20. Do you have a repository of code, test cases etc. for re-use?

Mar 6 2009   9:42AM GMT

Why software testing effort estimation is important after functional specifications finalization phase?

Posted by: Jaideep
software testing effort estimation, software testing, testing effort, functional specifications finalization, functional specifications, sizing of software testing effort, test case, testing time-line, testing timeline, testcase, quality standards, tester, testing, Test Plan, testing plan, test result, test report, development team, developer, software development, bug report, bugs report, testing guidelines, test plan guidelines, test estimation guidelines, testing knowledge, business rule, business process, functional coverage, bug-proofing

If we go by quality standards the sizing of software testing effort has to be done before the tester(s) start writing the test cases for the purpose. The estimate will clearly draw out of the functional specifications signed off between the customer and vendor. Without sizing the Testing manager can never create a testing plan based on which he will decide the number of days and persons required to write test cases, perform testing, draw out the testing results, submit the result report to development team and get the reported bugs resolved. The plan will comprise of time-line and no. of persons required for each of this phase in the sequence mentioned above.

To calculate a reasonable testing time-line estimate based on functional specifications there are certain guidelines that need to be followed: the person who is planning has to have ample business and testing knowledge. Unless (s)he has the right business knowledge (s)he will not be able to select the right persons for writing test cases, or able to guide them on the critical business rules and processes written in the software to hit upon. In that case the best of the test cases will lack the complete coverage and accuracy in testing. The software may lack bug-proofing at the end and customer will be the sole sufferer. Ultimately it is going to effect the software, and the organization that built it.