Project Initiation archives - Quality Assurance and Project Management

Quality Assurance and Project Management:

project initiation

Sep 25 2009   10:00AM GMT

What is the ‘unit to measure’ your project progress?



Posted by: Jaideep
Project Management, project progress, Software Project, project initiation, project closure, project feedback, project execution, Project Planning, project team, project milestone, project phase, Development, testing, UAT, QC, quality control, test report, sign-off, implementation, live run, project task

A project starts with initiation phase and ends up with project closure report. Then afterwards there is post project feedback (after a considerable amount of time given to the customer to get conversant with the product) and warranty support followed by support contracts over a period of time. Let us begin our story with the project initiation and proposal approval from customer. The real ball-game starts from here.

Now planning starts, teams are formed, milestones are set and teams move into execution phase.

Execution phase comprises of development, customization, configuration, testing, training, reporting, sign-offs, monitoring upto implementation, parallel run, live run etc.

And then comes the project completion phase with Project sign off.

During all the phases of project initiation, planning, execution… are the milestones broken into tasks and tasks further into sub-tasks unto the smallest measurable, achievable ‘hour’ unit. Or it is measured in days, weeks or months where it loses its continuity and rhythm. If everyday something is declared done, finished, achieved that is visible to the project team, stakeholders including customer, it carries out a satisfaction, rhythm, confidence and regular progress.

Mar 13 2009   10:07AM GMT

7 mandates for Customer Organization on Software Project “Ownership”



Posted by: Jaideep
1. Software Project Ownership, Software Project, specifications finalization, implementation, project manager, Key users, requirement freezing, implementation phase, UAT, project close-out, project milestones, Project Management, Project Plan, business practices, Business Rules, statutory requirements, project initiation

In software project there are two key agencies involved – customer and vendor. Both have to own equal responsibility in managing, monitoring and completing it successfully. In my earlier blog I have mentioned 6 mandates for Vendor Organization on Software Project Ownership. Here I would like to highlight 7 mandates for Customer Organization on OWNERSHIP in a software project. If both these mandates are followed, there is not doubt about the success of a project.

Mandates can be as below:
1. Involvement of top management during specifications finalization and implementation is mandatory: Most of the times customer management thinks their role only in signing off the project initiation documents and after that they feel it is the responsibility of the vendor team and their organization team managed by respective project managers to run the show and make it a success. This is a wrong concept, as the top management has to play a lead role in defining their expectations and requirements during specifications finalization phase of the project. They have to keep monitoring the progress of the project in later stages too. Generally what happens is that the top management do not define their requirements and expectations during this phase and at the final stage of implementation they feel robbed off as they realise that they are getting nothing or something they did not require or expect.

2. Project Manager and Key users should be identified well in advance and should be spared from all other responsibilities during requirement freezing and implementation phase: The top management should identify the project manager and key user well in advance based on their business knowledge, process ownership and commitment towards the organization. They should also ensure that this team’s top priority is now this project where they have to define specifications of requirements, UAT, implementation, reconciliations etc. And if they are engaged in their day to day routine activity or in any other critical program, they would not be able to do the full justification to the project.

3. Management has to ensure all milestone sign-offs – like requirements study, UAT, Implementation close-out etc: The management has to ensure that they mutually identify the milestones of the project. Proper sign off after each milestone achieved, monitoring of milestones progress etc. The persons understanding the gravity and seriousness of the matter should be authorized for signing off the various stages.

4. Project Manager has to ensure about the specifications completeness and validation during requirement freezing phase. Also he has to ensure his own and the key users’ availability during the project implementation, training and UAT phase: The project manager chosen by the top management has to ensure that accurate and complete requirements being documented validated by respective process owners. Since top management can not be involved in day to day activities of the project, he, being the project manager has to raise an alarm to the top management as and when he foresees any deviation from the plan or unavailability of key persons of his team who have to define the requirements or have to vet the validity of software meeting those requirements defined.

5. Project manager has to ensure the adherence of implementation plan timeline and any non-adherence has to be escalated well in time: As said above, Project manager has to be very careful and serious in this regard, and should be empowered enough to raise the appropriate alarm to the right person at right time at any level.

6. Top management has to review the progress of the project regularly as per schedule (weekly/daily): Top management has to have a process to monitor the progress of the project. The metrics could be plan vs actual or anything. Their involvement in monitoring the progress will definitely keep everyone in the team on their toes.

7. Persons dedicated for requirement freezing should be well aware of business practices, processes and statutory requirements of their organization and country: This is very important but not critically analyzed often. The persons identified for defining the process, requirements and business rules should be well aware of the business practices and processes of their organization and any statutory requirement of their country.


Feb 27 2009   9:54AM GMT

Software Quality vs Project Quality



Posted by: Jaideep
software quality, project quality, quality standards, quality measures, quality metrics, software metrics, Project Management, Software Project, customer requirements, software product, software design, business requirements, functional requirements, software delivery, Project Delivery, project execution, project initiation, Project Development, project implementation, software strategy, test strategy, test case, Test Plan, test scenarios, test results, fixing of bugs, project close-out, post implementation phase of project

The definition of QUALITY varies in different contexts. On one hand we talk of software quality that means adopting standards and measures to ensure the building of software product that meets all customer requirements (design, interface, business requirements, functional requirements etc.) and ready to deliver. On the other hand when we talk of Project Quality, we mean the standards and measures by means of building (or adopting) to ensure the success in terms of time and revenues of a complete project right from its initiation till the implementation stage that keeps continuing at post implementation stage also.

In context of software – the quality means – software strategy, plan, text cases, test scenarios, test results and fixing of bugs. Inclusion of quality in this context will vary from organization to organization and project to project (within an organization). This will ensure the successful building of software product ready for delivery.

In context of project – the quality would mean – managing quality standards and measures for a project right from its initiation to all stages coming forth. A project lifecycle in standard terms would comprise of Project Initiation, Project Planning, Development Execution, Implementation execution, Project Close-out, and post implementation phase broadly, which remains on-going till the software built is in use by the customer for a period of years.

The subject matter can continue on pages and pages, but the crux is – software quality is merely a subset of project quality, and even if we have world class standards in software quality, it does not ensure a successful project lifecycle.