project completion

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.

Jun 3 2009   10:00AM GMT

How to prepare for Post Project Implementation Review?

Posted by: Jaideep
Project Management, post implementation review, project manager, Software Project, project completion, project sign-off, project closure, software implementation, project feedback

Both vendor and customer have to understand that the real journey of a product starts only after a successful implementation of software at customer site. The challenges get a new meaning once the project team leaves the customer site after project sign-off. Both the managements can celebrate the successful completion of project. But it is better to hold on this celebrations for a while, till customer really learns to live with the product, starts tasting the real fruits of the product committed earlier. Let the key users start managing the show on their own, run the complete process in live scenario and get satisfied with themselves and the product. The project team that comes at customer site for implementation has a role related to post implementation review prior they go back home after successful closure of project. Similarly the management (customer) have to clearly understand their critical role once the vendor project team goes back after the completion of project. It is the key users and management (customer) now to run and manage the show. No doubt that the vendor team is always at the back to support and assist them in achieving this. Let us assume that the project is over and team is about to leave the customer site. At this juncture it is the prime responsibility of vendor and customer project managers to shake hands and understand the importance of post implementation review in following terms:

The Project manager from vendor side has to hand over the post implementation review plan to customer at the time of implementation sign off and explain clearly each and every agenda of the post implementation review. The clarity in terms of product, managements, users, usage and product is very important for assessment purposes after a stipulated period.

The project manager from customer end has to ensure to get the post implementation plan for feedback purposes at the time of implementation sign off. This will not only leave the project open for another some time in terms of providing a lease for customer team to assess and experience the product in complete isolation in their own terms.

The purpose ultimately is to share the overall health of product, the key users, and the management.

May 18 2009   10:00AM GMT

Vendor’s role in involving customer top management while requirement gathering phase

Posted by: Jaideep
Software vendor, Project Management, Software Project, Software Project Lifecycle, business study, requirement gathering, customer, customer expectations, software product, top management, project stakeholders, process owner, end user, software development, project completion, user level requirement, top level requirement

The most critical stage in software project lifecycle is business study and requirement gathering. Vendor has to be very cautious and careful in understanding all levels expectations from the product they are going to build for the customer. Skipping top level at this stage could be disastrous for both. As a vendor, if you don’t involve customer top management while gathering requirements – you are inviting a mishap!

Customer top Management involvement is very critical during the business study and requirement gathering phase of a software project. The expectations of top management shall invariably be different as compared to other stakeholders of the software project at customer end. Assuming that the requirements gathering from process owners or end users will be sufficient for developing software will be a misconception. A detailed discussion for capturing requirement and understanding top management perception is critically important to lead to a successful completion of the project.

At the Vendor end – the Project Manager has to ensure that besides capturing user level requirements, it is essential to highlight the benefits to the top management being proposed for them from the product. It is not desirable but mandatory to freeze top level expectations at business study and requirement gathering stage.

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.

Feb 25 2009   10:02AM GMT

Top 20 End Objectives of any Software Project

Posted by: Jaideep
Software Project, software business, software project management, project objectives, business survival, growth, revenues, profits, maturity, Project Lifecycle, standards and methodology, software metrics, stakeholders, transparency, project completion, project sign-off, customer satisfaction, customer delight, customer requirements, software requirements, Team building, team role, team responsibility, team accountability, software quality, project quality, first time right, project overrun, continuous learning, Increase in revenue, Avoid revenue loss, Reduce costs, Avoid cost increases, Improved service

Certainly and obviously, every business has a set of objectives. Every business strives for survival, growth, revenues, profits, satisfaction and maturity. The clearer the objective are, the easier it is to achieve them. To achieve the objectives, if the destination is clear, it becomes easier to set the direction of the business, to set the milestones, to chalk out the roadmap, to set the drive, to decide the pace and to achieve them. The top 20 end objectives of any software project can be listed as below (note that the hierarchy is not as critical as the understanding of the gravity of each of the objective):

1. Control on Project Lifecycle

2. Standards and Methodology

3. Metrics

4. Stakeholders rights

5. Transparency

6. Pro-active approach to avoid post-mortem

7. Universal approach for similar projects

8. Timely completion, sign-offs and payments

9. Customer satisfaction and delight

10. Customer requirements and both end clarity on objectives of the product

11. Team building

12. Roles, responsibilities and accountability

13. Continuous Learning from failures/ overruns – no repetition of same mistakes to achieve continuous improvement overall

14. First time right approach

15. Quality right from start – ongoing – every step

16. Increase in revenue

17. Avoid revenue loss

18. Reduce costs

19. Avoid cost increases

20. Improved service

Feb 11 2009   11:04AM GMT

Project Management – Tasks vs. Milestones

Posted by: Jaideep
Project Management, project manager, Software Project, project task, project milestone, software team, programmer, developer, technical, coder, coding, programming, Development, Project Development, project progress, project completion, PM

A new project is always divided into small tasks and based on the resources available, the task(s) are allocated to individuals by the project manager (PM). A simple metrics is important to follow to monitor (and manger) the completion of tasks and thereby figuring out at any moment of time – the progress of the project. Completion of all tasks automatically declares the completion of the project.

Customer and management will never be interested to go into the detail of each task, PM (you) and your team may be and should be. But your one of the major task during a project is to keep customer and management updated on what is happening, regarding the progress of the project.

Your team of individual developers, programmers, coders or other technical related functions, although have accountability for the tasks assigned to them in individual for which they put in all their efforts to meet your/their completion plans as per the targets set.

So far so good, but as far as satisfaction, and feel of achievement is concerned, you need to group a set of tasks (the important ones that really give sense of achievement) into milestones. The customer and management will be interested in milestones achieved instead of tasks completed. Your team members will feel motivated, inspired and cheerful on achieving these milestones. And above all you will have time to appreciate and celebrate your team’s achievements that you can not do rightfully in case of tasks.

Milestones have more visibility as compared to tasks.

Feb 9 2009   9:55AM GMT

Mr. PM, what metrics you use for measuring “Task Completion”

Posted by: Jaideep
Software Project, Project Management, project manager, PM, project metrics, Project Status, project completion, project task, project progress, developer, programmer, coder, coding, Development, programming

It is not important what metrics you (the project manager) use, because unless and until you understand the meaning of “task” and “task completion”, you can’t get into the mode of monitoring and measuring it. The progress (or completion) project as a whole is measurable only if it is broken into pieces termed as “tasks”. Based on your resources you can allocate different tasks to different developers/ technical guys. But again the questions arise are – “what do you want to measure?” and on top of it, “do you really want to measure?”. If the answer is “yes” for the second question, then you will start thinking about “how to measure?”.

Metrics or method of measuring is not critical, it is the “what” that matters most here. So when you break up your software project into tasks, those should be measurable and the person doing it has to be accountable for it. Before making your programmer (or the technical person) accountable for a task, you have to evaluate – “is (s)he is fit for the task being assigned?”.

Your method of measurement will decide the clarity of progress of project to you, your team, the management and to the customer. Don’t accept a report from your subordinate declaring a task as completed unless you yourself are convinced. For your conviction you can get it checked by another coder, technical person or quality person, or you can check on your own, depending on the criticality of the task. Since you are going to report to management and the customer about completion of a task, it is important to confirm beforehand.

Transparency about the project progress is as important as the authenticity to both – the management and the customer.

Integrity of task completed is another measure that you have to take into account for your project completion.