software requirements

May 11 2009   10:12AM GMT

Two aspects in Change Management in Software Project

Posted by: Jaideep
change management, Software Project, Project Management, project cycle, Project Development, software development, software implementation, project implementation, software requirements, business requirements, business study, project manager, Business Rules, customer management, customer requirements, project team, business critical change

Change management is a subset of project management. In any software project change is to be managed during the whole cycle of development and implementation. Requirements once specified by customer at the business requirements study phase does not mean that there will be no change in requirements later. Vendor who is not open to mange or cater to this change in requirements will not be able to deliver the product to customer upto his satisfaction. To mange these changes Change Management is essential and both have to play their respective roles in managing the project. Changes could be in terms of specifications, process being re-defined, or change in business rules. The two aspects for change management are – vendor and customer.

At Vendor level the Project Manager should accept changes only that are business critical and not cosmetic or wishful in nature. He should redefine the project/ development/ implementation plan in terms of time and revenues in consultation with his management taking customer management in confidence. He should incorporate changes only after getting it approved by customer top management.
The Project manager has all rights to challenge any change in requirements that is fanciful, not business critical and is impacting the software largely in terms of efforts and time.

At Customer level the Management and Project team have to understand the impact of any small change on the software thereby asking for a change only if it is a business critical change, analysing if the change can be avoided, and understanding the time and cost effect of the change.

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.

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