Project Plan

Nov 6 2009   10:00AM GMT

Ten cautions in case of a self sponsored project

Posted by: Jaideep
Software Project, Project Management, Development, software development, Risk Management, risk mitigation, risk severity, project sponsor, project methodology, Project Plan

What if you have chosen to develop a product for which you don’t have a customer right now? If you perceive that by the time you complete development phase and the product will be ready to launch if will not be obsolete as per technology or concept, go ahead but take care of following cautions to be a winner in the game:

10. Technology: Ensure that you are starting with the latest technology, as even the latest technology will be a little older by the time you complete the product.

9. Concept: Ensure that you do not start building a product that has several variants already in the market. Beat the drum to give the world a new beat.

8. Keep the air in your bag: Let the concept not leak out until you are ready to launch the product. Launch it with a bang. Advertise, blog, press conference, and whatever you feel appropriate for the launch. But ensure that your team confide in you in this exercise till you are ready to shout.

7. Convince, build trust: Convince yourself that you have chosen a right path even if it is risky. Demonstrate your management about your idea and the way you want to design/ launch it. Build trust among your team in giving a real shape to your dream.

6. Risk Management: It is very essential to jot down the risks involved, and ways to mitigate them depending on their severity.

5. Incentive: Let your team know what incentive they are going to get once the product and project is successful.

4. Project Sponsor: Mostly in such type of projects your management will sponsor the project, so all risk lies inside the house. Your stake is quite high in such projects. Equally important is the success of such projects.

3. Project Methodology: Adopt the right methodology and adhere to its requirements.

2. Project Plan: Ensure that such projects cannot tolerate much deviation in terms of time or money. Since in such projects all risk is yours, don’t let it increase at any cost.

1. Definition of successful project: Building a beautiful product in this case is of not any use if there is no buyer at the time of launch. Your total investment in the project can return only if you are able to find out a buyer.

Nov 3 2009   10:00AM GMT

Project Plans having no Place for ‘Documentation Process’ Compromise with the Quality

Posted by: Jaideep
project documentation, Project Plan, project quality, quality, project stage, software, software quality, testing, software testing, project implementation, Project Lifecycle, Project Management

If we have to compromise with the quality of project at various stages there are many ways to do that. Most stupid way will be to compromise with the quality of the software which in any case is going to create lot of hue and cry in the organization either prior to it goes to customer during internal testing, or when it goes to customer for implementation. The undercover holes covered howsoever smartly will create seepage sooner or later.

Most common mistake that is made during the complete lifecycle of a project is not formally giving documentation (required at various stages) in project plan by assuming that documentation is not that prime. It is presumed that either the documentation will be done at the end or it is taken too casually and told to be done by everyone without assigning a proper ownership.

Both – Quality of Software and Quality of Documentation play a lead role in project management. Compromising with any of the two leads to increased cost, loss of customer satisfaction, delay in implementation or revenue loss.

Jul 8 2009   10:00AM GMT

The life of a Project Manager in a Software Project

Posted by: Jaideep
Project Management, project manager, project team, project monitoring, Project Plan, Project Planning, Project Development, project implementation, Software Project, software development planning, software product

At the birth (inception) of a new software project the project manager is puzzled and confused just trying to gather and understand customer requirements. He starts like a wanderer in the dark islands of customer for collecting various requirements and understanding their business norms. The moment he is able to collect this information, he aggregates to get the stock of ‘total requirements’. Understanding this makes him getting into ‘catching the rhythm’. Now comes his planning phase where he has large ‘in depth’ discussion with his development teams. By identifying different milestones for various project stages, he prepares a project plan. At this stage he is supposed to discuss this plan with customer and get ‘in sync’ with him. Once approved from customer, he breaks this plan into different stages plans to hand over respective plans to their ‘stage owners’. Development plan goes to development manager. Quality plan goes to QC head. Implementation plan goes to implementation head (himself mostly). Accordingly each stage milestones are identified which might be more than overall project milestones shared with the customer.

Then starts the actual war phase – the development phase. Meetings, discussions, brainstorming, logs, monitoring are all the weapons of this war phase. A product gets birth during this phase which gets vetted by quality control team. Documentations are also integral part of this phase.
Various test phases occur during and post development or build phase. Smoke testing, Unit testing, module testing, performance testing, security testing, load testing, functional testing… to name a few.

Now the baby has started walking. So baby is dressed well to take it to the grand function taking place at customer site. The function is ‘Implementation’. This is a long function, comprising of baby show, meetings, discussions, demonstrations, recordings, UAT, training etc. Once the baby is able to walk neatly in front of all the guests at the function, all praises fall on baby. The ceremony closing takes place. Project manager adds one more bullet of ‘confidence’ in his gun.

And starts over again for a new project.

May 15 2009   10:10AM GMT

How to manage Change Management – in terms of scope of the project

Posted by: Jaideep
Project Management, change management, project scope, project schedule, Project Plan, Software Project, project manager, project progress, project role, project aspect, project study, project location

Scope defined and decided upon initially by vendor and customer mutually has a large impact on timeline, progress and success of a project. A change in scope at a later stage may call for a big impact on project schedule and progress. Let us see the roles of vendor and customer respectively in this aspect of project.

Vendor - Project Manager has to ensure that the scope of project defined in the Business Study Document has to be adhered to. Any change in the scope (increase or decrease) has to be escalated to both the managements and the project plan has to be re-designed thereupon.

Customer - The management and project manager has to ensure that they define the Right scope for the project (number of locations, pilot site etc.), also understand that any change in scope will adversely effect the project plan and hence seeks redefinition. The pilot site chosen should be the best possible site in terms of testing the software completely and rigorously.

May 4 2009   9:40AM GMT

Roles of Vendor and Customer Project Managers to avoid Project Overrun

Posted by: Jaideep
Project Management, Software Project, project organization, project sign-off, project completion, project overrun, project failure, project time, project revenue, project approach, project metrics, project progress, Project Plan

Project management is a joint effort of vendor and customer teams. Project Organization members have to play their respective roles timely and religiously to get the best of the results. Both have to go hand in hand right from the start of the project till end and even beyond. The relationship does not end with the successful completion of the project. Rather a new journey starts with the project sign-off. The baby borne by the vendor team with the help customer team changes the hands with the project sign-off. If these responsibilities are not well understood well in advance, it may lead to overrun and may end to the total failure. To avoid a project overrun the vendor and the customer have to trigger the alarm well in advance as soon as they sense a sign of overrun arising out of any reason.

At Vendor end the core responsibility of project manager is to train the customer project manager in project management so that customer project manager takes the lead in project and ensures that there is no overrun in terms of time and revenues.

At Customer end the customer Project Manager has to be pro-active in his approach to escalate the matter to his top management in case he feels in advance that project is going to overrun (with reasons identified and agreed upon mutually). Some suitable metrics can be used as project plan to trace the progress of the project in accordance with the project plan.

Apr 27 2009   10:06AM GMT

Project Overrun – what is crucial – time, money or both?

Posted by: Jaideep
Project Management, project overrun, project implementation, Software Project, software implementation, Project Plan, Project Planning, project manager, project organization, project monitoring, overseas project, domestic project

A classic scenario happened in an organization recently as told to me by a project manager of that organization engaged in software development and implementations.

It is related to project overrun.

A new project started with a set of requirements from a customer for development and implementation. It was an overseas project so project cost was comparatively higher than the domestic project. The respective teams for business requirements, development, configuration and implementation were formed. All went well till the implementation phase. The implementation team was ready to take the charge for on-site visit with the product to launch there.

The implementation phase planned was 4 months. Somehow due to a mix of reasons, it took 18 months to complete the implementation.

The team came back after successful implementation. The customer paid the full project cost as was accepted upon in the beginning.

The project was declared as successful without any overrun. For overrun cost was taken the criteria and since full cost was recovered, it was treated as not overrun project.

Is that right?

Throwing some points to ponder upon:
The cost that had to come 14 months back came now.
The team that has to return 14 months back arrived now.
In this period of 14 months atleast 3.5 projects of similar nature and size would have been completed.
The project manager is over-optimistic.
Project monitoring was very poor.
Etc.
Etc.
Etc.

Apr 24 2009   10:06AM GMT

5 ways to control project overrun

Posted by: Jaideep
Project Management, Software Project, project momentum, project velocity, project cost, project time, project organization, customer engagement, project sign-off, project closure, project training, Project Plan, Project Planning, management involvement

Project overrun is simply a project crossing its boundaries set by the organization. These boundaries may vary from organization to organization depending on how they blindly or how over-extensively (both extremes) they want to look at it.

5 ways to control project overrun could be:

1. Requirements: With any change in requirements from customer, effort estimation and change in plan is important to drive the project in right direction.

2. Customer engagement: At customer site (or earlier as and when customer involvement is required) if customer project team is not justifiably involved in project by means of specifying requirements, providing master inputs, in training, timely sign-offs at various stages, hands-on exposures, etc. effects project drastically and plan may go haywired, without anybody’s accountability to prove, if alarm is not raised well in time.

3. Milestones: If appropriate milestones are not identified and monitored at every stage of the project, it affects the project finish off in time.

4. Management involvement: If management let the project go off without their involvement in it, it has high chances to overrun.

5. Celebrations: No celebrations of achievements during the project can decelerate the tempo and momentum of the team at both ends to finish off the project in time.

Apr 22 2009   9:51AM GMT

5 myths about Project Overrun

Posted by: Jaideep
Project Plan, Project Planning, Software Project, project overrun, project acceptance, project organization, customer requirements, software requirements, Project Management, project closure, project manpower management, project cost, project timeline, project timeframe

All projects are prone to overrun. An overrun acceptance is directly proportional to an organization’s fault absorption capacity. Accordingly the definition of overrun is framed to demonstrate an overrun project as rightly completed project.

5 myths about Project Overrun could be:

5. Planning: After the initial plan is made, customer requirements have shrunk but it is good not to revise the plan to achieve in-time project closure (or even earlier).

4. Manpower: Project Plan is made after which additional manpower is inducted in the project, but no need to revise the plan.

3. Cost: Customer is ready to pay the full payment to complete the project, even if it overshoots the timeframe decided as per plan.

2. Time: A project had to complete in 5 months, but it took 10 months to complete. Imagine the manpower engaged in this project that could have finished another project if this project finished in time.

1. Customer: Customer is not able to cope up with plan but not ready to pay for extra efforts being done by the project team on behalf of customer thereby overshooting cost and time. We have a valid reason for this overshoot.

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 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.