Apr 29 2009 10:18AM GMT
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
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 22 2009 9:51AM GMT
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.
Feb 25 2009 10:02AM GMT
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
