project organization

Oct 21 2009   10:00AM GMT

Performance Management has nothing to do with the Project Size

Posted by: Jaideep
Software Project, Project Management, project organization, project methodology

Be it large organization or small performance management is the key concern for any size of organization. Every organization has a goal to achieve their goals bound to be for a stipulated period, gain profits, enhance, and set higher targets. Growth is important for every organization.

The same applies to project also. Irrespective of its size, client, and customer requirements, each project has to be a success if in turn the organization has to achieve success. For that purpose performance management becomes a great tool. There has to be a performance management methodology clearly defined for that organization so as to assess the performance of each individual of the organization involved in the project directly or indirectly. A performance methodology should very clearly define the process of measuring performance. The process should be transparent, acceptable, measurable, and simple. Any cumbersome process is good for document purposes for difficult to adhere to.

The methodology should be universal for all the employees at all levels as it is very clearly evident that a project is like a relay race. The overall performance is highly affected by the weaker links. Even if there is a weak member in a very strong team, it is high risk for the overall project. As each member has to perform their individual task, in today’s scenario of recession, lean and low costs, each member’s performance keeps overall organization’s performance at stake.

Jun 10 2009   10:00AM GMT

Ten Reasons of getting into pitfall of leaving a scope of software development at customer site

Posted by: Jaideep
Project Management, Software Project, change management, project organization, developer, project sponsor, project director, project manager, key user, implementer, technical lead, business requirement study, business analyst, business analysis, requirement analysis, requirement gathering, implementation phase, project phase

In the previous post we learnt what all could a software project could lead to in presence of higher scope of software development at customer site during implementation phase. Let us see what all factors are responsible of insufficient requirement gathering during business study phase of a project.

1. Incompetent team (vendor): Any project calls for a project team. A good team at both ends is important. Both teams have a substantial role during a project. If key users selected at customer site for delivering process knowledge to requirement analysts (vendor), there are higher chances of wrong information driven. The key users chosen should rightly be the actual process owners not essentially be at the higher level in the organization.

2. Incompetent team (customer): A right selection of project manager and analysts is equally crucial. The team has a short duration stipulated for gathering requirement information and understanding business processes. And mind it, this is not an individual race, it is a relay race, and weakest link will decide the overall result of the project.

3. Non commitment (customer): Well the process owners are the key users, but if are not serious or have not received the right message from their management may not be seriously committed to the vendor team. A non committed team will not be able to impart right knowledge, processes, practices and information required critically for a project.

4. Non commitment (vendor): A team of good committed project manager and analysts is equally crucial for gathering information. The previous experience on business domain and success factor definitely counts in.

5. Lack of time (customer): Key users identified if are engaged in other important projects running in the organization will be always short of time for providing right information to vendor project team.

6. Inappropriate discussions: In a limited timeframe of business study, there will be limited discussions. So all discussions should be crisp, purposeful, well driven and result oriented.

7. Improper documentation: Well explained requirements if not documented properly may lead to a wrong, incomplete product. Right people with right business and process knowledge have to acquire a good documentation skill also to lead the project to right direction and grand success.

8. Top Management involvement (customer): If customer management thinks that providing key users completes their job in the project, they are wrong. Their involvement in all important meetings is as important as the business is.

9. Project Organization: A right architecture of project team is very important. The project sponsor, project directors, project managers, key users, developers, implementers, technical leads from customer and vendor respectively should be the right mix of people.

10. Change in requirements: Any change in business or process during or after the requirement study phase has to be communicated to vendor team well in time, so that by following the change management procedure, the changes are taken care of properly.

Jun 8 2009   10:00AM GMT

Five pitfalls if you are leaving a scope of software development at customer site

Posted by: Jaideep
Quality Assurance, Software Project, software development, Project Management, project organization, project team, project delay, project completion, on-site development, testing, tester, QC, quality control, project implementation, software implementation, functional lead, technical lead, quality, software quality, project quality

Ideally, in a software project, for an offshore customer, the requirement gathering phase should be given an extra care to understand to a maximum extent so that the product developed and tested when ready for implementation at customer site requires no development. Practically, it is very difficult to achieve. The more it is left open to be handled at customer site, the higher is the chance of customer and vendor getting affected.

So that means the higher scope of development at customer site will change the team requirement and affect the overall project. Let us see what major factors will get affected and where could those lead the project to:

5. Money Factor: The most important factor is money. Any scope of development at customer site will need extra developers in the team besides the implementation functional leads. This will lead to an extra burden in terms of cost of technical staff not only in terms of developers but also testers.

4. Time Factor: Delay in project is inevitable in these circumstances when
requirements will be clearer at customer site at the time of implementation and
thus will change the overall implementation plan to accommodate development
and testing in between.

3. Quality Factor: Poor quality will be a major concern. Everyone knows you can not
take a bundle of testers at implementation site. That means limited testers will be
in under a tremendous pressure to release the product at the earliest and hence
may not justify with their job. This may lead to lot of holes in the pot –
intentionally left or unintentionally skipped.

2. Exuberance Factor: Enthusiasm, tempo, momentum, pace will all start
diminishing and in turn start creating frustration and dissatisfaction at both teams
level.

1. Product Factor: Product Failure, if not, then delays and unpolished product is
always visible on the platter under these circumstances.

All these factors, being inter-related will have recursive effect on each other thereby increasing each by manifold and everything may turn into a complete mess in place of a successful project.

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