UAT

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.

Sep 9 2009   10:00AM GMT

How do you do your project sizing?

Posted by: Jaideep
business application, Software Project, UAT, software product, Project Management

Next month is a marriage in your close relation. You plan to buy an expensive suit length and get it stitched by the best tailor in the city. You buy the best cloth, go to the best tailor, he takes your measurement and gives you a trial date suitable to you. You go on that date, find minor or no change in the stitched suit, tell him the alterations required and get your fully perfect suit after 2 days, a week before the function date.

Your customer decides to go for a business application, decides on you to build it and implement it, gives you an order, you take the measurement (understand business rules and customer requirements), you give them the tentative date for trial (UAT)… but UAT goes down flip flop. You are not able to deliver the product on promised date.

Your tailor delivered the suit, with your complete satisfaction, on the promised date.

Where is the difference? Something went perfectly between measurement and trial date for your suit that your tailor had to deliver to you but not for your product that you had to deliver to your customer.

This is called product sizing and team sizing i.e. project sizing.

Aug 5 2009   10:00AM GMT

User Acceptance Testing (UAT)

Posted by: Jaideep
UAT, user acceptance test, testing lifecycle, software testing, product testing, software product, software development, customer specification, interfacing, functional testing, functional requirement, functional specification, business rule, business process, integration test, software build, validation testing, defect fixing, bug fixing, software defect, software bug, appearance testing

UAT or user acceptance testing comes as the last exercise in software testing lifecycle. It is probably the first phase or beginning of customer preparing to takeover the charge of the product. Actually this is a sort of test drive by a perspective buyer who has studied well about a car, has made up his mind to buy it but wants to satisfy himself by actually sitting in the car and driving it. Even if you have made up your mind to buy a particular model and after sitting in the car or after having the test drive, something does not suit you, the decision can take 180 degrees turn.

The same usually does not happen in UAT because the unlike car the software has been built as per customer specifications. UAT usually includes interfacing (if any), look and feel, ease of usage, functional requirements, integration test etc.

Like a car test drive, here also use runs the complete software to assess if the software is meeting their requirements completely or not. It is the last place where the user gets to determine whether or not the software meets his or her requirements. But one thing is very clear – whatever defects occur during UAT, their fixing cost goes manifold as compared to the same defects occurring during the initial building of software.

Main difference between the earlier testing done at development place by testers is that here the business process and validations built in the software will be checked by a business process owner with real data.

Probably in this busy world, if the end user, by any chance is available during the development and testing phase to do appearance, functional, process and validations testing, it would save a big amount of time and money.

Apr 20 2009   10:05AM GMT

Role of customer project manager at customer site during implementation stage

Posted by: Jaideep
project manager, Project Management, project implementation, implementation phase, project lead, project ownership, UAT, business study, business need, software training, implementation process, implementation plan, project team, Risk Management, Risk Plan, post implementation, process owner, reconciliation, transaction entry, project sign-off, project closure, project failure, project success

The customer project manager has to take the lead and ownership of product as soon as it is launched at customer site for implementation. The UAT, training and implementation process can only be effective in case customer project team gets fully involved into each and every activity of the implementation phase. Infact the implementation plan prepared by vendor project manager should be the responsibility of customer project manager to execute.

Customer Project manager and management has to clearly understand the risks involved during the business study, implementation and post implementation phase as highlighted by the vendor Project Manager and to act thereupon to overcome those risks with suggestions from vendor project manager.

These risks could be in terms of consequences involved:

if requirements are not complete and well defined,
the involvement of users and process owners during business study, implementation, UAT, masters creation, transaction entry, reconciliation etc.,
if sign-offs not happening in time, etc.

Even if the sign-off is given and product is not put in use, there is a chance of project failure at both ends.

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.