April, 2009

Apr 29 2009   10:18AM GMT

Project Overrun – who to blame

Posted by: Jaideep
project overrun, Software Project, project manager

Project overrun is not unknown for any software organization. Every organization who has tasted it would acknowledge that it is always painful – in terms of time, cost and resources. Ultimately when the other two factors are also converted to cost, it comes to a voluminous figure. Nobody wants it, but in many projects despite all good efforts it becomes unavoidable and then some valid reasons are listed to justify it. Usually as the project overrun starts – simultaneously starts a hidden tug of war between the vendor and the customer.

Customer gives a different set of reasons all pointing towards the vendor to prove that it is the vendor who is responsible. Vendor on the other hand tries to justify that there were n number of shortcomings at customer end that caused it.

And that becomes a major cause of more overruns… sometimes endless…

Instead even at this juncture, when an overrun starts, if both the parties sit together and find out the root cause instead of finding out reasons to blame each other, it would be helpful in stopping further delays.

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.

Apr 20 2009   10:05AM GMT

Role of customer project manager at customer site during implementation stage

Posted by: Jaideep
project manager, Project Management, project implementation, implementation phase, project lead, project ownership, UAT, business study, business need, software training, implementation process, implementation plan, project team, Risk Management, Risk Plan, post implementation, process owner, reconciliation, transaction entry, project sign-off, project closure, project failure, project success

The customer project manager has to take the lead and ownership of product as soon as it is launched at customer site for implementation. The UAT, training and implementation process can only be effective in case customer project team gets fully involved into each and every activity of the implementation phase. Infact the implementation plan prepared by vendor project manager should be the responsibility of customer project manager to execute.

Customer Project manager and management has to clearly understand the risks involved during the business study, implementation and post implementation phase as highlighted by the vendor Project Manager and to act thereupon to overcome those risks with suggestions from vendor project manager.

These risks could be in terms of consequences involved:

if requirements are not complete and well defined,
the involvement of users and process owners during business study, implementation, UAT, masters creation, transaction entry, reconciliation etc.,
if sign-offs not happening in time, etc.

Even if the sign-off is given and product is not put in use, there is a chance of project failure at both ends.

Apr 17 2009   10:03AM GMT

Role of vendor project manager at customer site during implementation stage

Posted by: Jaideep
project manager, software implementation, project implementation, Project Management, project team, project lead, Risk Management, Risk Plan, implementation plan

The vendor project manager has to work as a consultant to the customer project manager rather than taking the full command at customer site during implementation phase. From vendor side, it is the responsibility of the project manager to highlight the risks (in terms of user’s availability, user’s understanding level, or about the product usage) to his and customer management and a plan to overcome those risks. He also has to ensure that the solution provided is in line with the business needs.

He has to make the customer management totally convinced that it is their product which they have to use in real life scenario and hence they have to be fully confident in that. The vendor management has to be with him all the time for this.

Apr 16 2009   9:40AM GMT

Responsibilities of project manager during project implementation phase

Posted by: Jaideep
Project Management, project manager, Software Project, software implementation, project closure, implementation plan, project lead, project team, software acceptance

Project managers (the customer end and the vendor end) have to work hand in hand during the implementation stage of a software project happening at customer site. The key responsibility of both the project managers working on the project is to ensure successful implementation and project closure.

It is the customer project manager who has to take the charge, be in full lead and command to drive the project and keep the responsibility and onus to him and his management. The implementation plan has to be his baby all the time. Unless and until he takes the lead, he will not be able to put the potential fire in his team to accept the product. And then only he will be able to ensure a fully hassle free implementation.

Apr 13 2009   10:01AM GMT

Project Manager’s vision has to be perfect 6/6 for project implementation

Posted by: Jaideep
project manager, Software Project, project implementation, Project Management, Project Lifecycle, software development, software testing, software implementation

No project manager can claim there was not a single problem in any of his projects. But then he is to tackle them. To tackle them he should be aware of them. To be aware of them, he has to have an ability to foresee them than to overlook them. The earlier he envisages those problems, the more time he will get to dig into and find out a countermeasure. No software project is problem free, but then… the project manager has to be alert and have a perfect vision to oversee them, accept them, plan accordingly and win over each of the issues.

Problems will definitely be there, in all phases of project lifecycle. It is the vision that you envisage them in advance and prepare yourself to overcome them.

The deficiencies do not get so highlighted during in-house development and testing phase of the product. But it becomes prominent any problem that arises at customer site during the implementation phase, or say post implementation period.

Apr 10 2009   9:59AM GMT

Application developed, tested and built well does not ensure successful implementation

Posted by: Jaideep
Application development, software development, application implementation, software implementation, post implementation, successful implementation, project manager, software project manager, project vision, project sponsor, project director, stakeholder, software testing, application readiness, Project Management

It is not only the project manager but all stakeholders who get affected by the project over-run or failure. It could happen due to any reasons. One of the major reasons that have emerged is the lack of vision of the project manager, project sponsors, project directors and other stakeholders to foresee the problems faced by customer during implementation or post implementation while using the product.

The product may have been developed well, tested well and built well to launch, but what happens if some soft issues that may arise during implementation or even post implementation period are overlooked. It could lead to a disaster…

Apr 8 2009   10:18AM GMT

10 stages of Risk in software application development and testing

Posted by: Jaideep
Software application, software development, software testing, application testing, risk, risk perception, risk identification, risk assessment, Risk analysis, impact analysis, risk classification, Risk Plan, risk plan analysis, risk plan execution, risk closure

A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.

Let us understand the different stages of risk in software application development and testing phase:

1. Risk perception
2. Risk identification
3. Risk Assessment
4. Risk Analysis
5. Impact Analysis
6. Risk Classification
7. Risk Plan
8. Risk Plan Analysis
9. Risk Plan Execution

10. Risk Closure