Project management business case
dbms2014
case_study_project_management.docxCase Study: Retailer XYZ
As a retail consultant for one of the world's most reputable consultancies, you have been asked to project manage the implementation of a new merchandising system for a key, high profile UK retail client, Retailer XYZ. This client has a single store in the UK and has been operating for many years on a range of inhouse built legacy systems which will no longer support their strategic objective which is to grow their operations internationally by opening new stores.
Your project is one of many IT projects. You are focusing on the merchandising area and you have been notified that as part of a wider programme of change there are plans to include a warehouse management system implementation and a planning/forecasting project consisting of a series of enhancements to existing processes and applications. As the project manager you will need to be mindful of these other projects if your project is to be a success. Waterfall is also the client's preferred method for delivery which you need to incorporate into your planning.
With regards to the people aspect of this project you will report to an overall Programme Manager who is from your organisation; she will work with an equivalent from the client. The Programme Manager will report to a Programme Board which consists of Senior Client stakeholders and Executives from your consulting organisation. For your immediate project team, business users will be seconded from their areas to join your project once a plan has been produced and mobilisation of the project commences. You will also need to determine the number of consultancy staff and contractors you require to support the project. To date no merchandising solution, budget or plan has been selected or developed. You are joining the project at the very start of its inception.
First things first, you need to understand why the client needs to change, what the drivers are and what the business hopes to achieve from this significant investment.
As the Project Manager you need to understand why Retailer XYZ has engaged with your consultancy organisation.
Case Study: Drivers for change
From conversations with your Programme Manager and key Senior Clients you have ascertained that the organisation would like to migrate from a single store entity to a multiple store entity not only in the UK but also in other countries. Their current systems were originally developed inhouse and have been coded to accomodate a single store only. If the organisation is to grow the curent technical architecture would not support this increase in volume of transactions plus the cost and time to enhance the current systems can not be justified. Retailer XYZ's competitors are well underway with store expansion plans and are benefitting from the additional income generated and positive customer feedback.
In terms of internal operational efficiencies, stock management across multiple warehouses is performed manually by warehouse staff. Inefficiencies associated with this plus the growth plans suggested above indicate this is not a sustainable practice and therefore a warehouse management systems needs to be introduced to support stock management and control. The warehouse management system will also need to be integrated to the merchandising system for stock replenishment requests to store and intra stock transfers between stores.
Case Study: Business case development and funding
With any investment decision it is essential an organisation has as many facts as possible before a substantial commitment and investment is made. Any change, however small, will come at a cost and have an impact.
For Retailer XYZ the desire to change originally came from the Board. Senior Management from various departments were then tasked with an impact assessment to understand the implications of moving from a single store to a multiple store set up. This impact assessment considered many facets including: IT, People, Processes and Cost of change.
Once the impact assessment was complete, findings and recommendations were shared with the Board. The next stage was to understand the options available to them for the merchandising and warehouse management systems - key questions would have been do they develop in-house or buy in? This is where business case development is key.
Before any release of funds or mobilisation of a programme or project, Retailer XYZ needs to produce a business case which has to be signed off by the Board. This can take many months to achieve took several and multiple iterations to gain agreement. Income generated from issuing of shares will part fund the investment and there was a risk of little or no dividend payouts if the wrong choice is made. Another key factor is that ALL Board members have to sign off the document.
The Retailer XYZ business case included several key sections which are listed below:
1. Purpose of the business case document
2. Reasons for the change (or drivers)
3. Options
4. Benefits Expected
5. Risks
6. Cost
7. Timescales
8. Investment Appraisal
Retailer XYZ has to consider the Build vs Buy decision. Business requirements are solved either by building a new system or by buying a readily available product or by a combination of both. The 'Build vs Buy' decision will be made by the stakeholders after weighing various parameters. A 'Build' decision results in tailor made projects (also known as bespoke projects or custom development projects) whereas a 'Buy' decision results in product or package implementation projects. The technical, functional and managerial challenges vary between these two options and therefore the practices during project execution vary as well.
Benefits Expected, Retailer XYZ needs to consider both hard and soft factors here. Hard or tangible measureables included cost savings, process efficiencies, improved stock management and control, reduced customer complaints, improved availability of IT systems, revenue increase from additional stores, share price improvements. Soft factors or more intangibles factors included improved employee engagement, improved market confidence.
Investment Appraisal, Retailer XYZ needs to understand for the money they planned to invest in the programme, how quickly could they recoup the money. With shareholders involved this was important to calculate as they will be interested in pace and how quickly a positive cash flow can be generated.
Conclusion
Based on the information presented in the business case and other variables such as risks and costs the Board decided to 'Buy' the solution and engaged with your consultancy organisation to support the decision making process in relation to which IT solution to select. Your consultancy organisation was also asked to support the implementation of the solution.
Vendor selection and contracting
Your client has now requested your organisation is to be responsible for the vendor selection process for the merchandising project. The outcome of this process is to determine which vendor you will work with for the duration of the project, the preferred solution and the vendor contracting arrangements.
Retailer XYZ follows a simple 5 stage vendor selection process which you have been asked to manage and co-ordinate along with involvement from key client business and IT members of staff. The Programme Board wants the vendor selection process to be as swift as possible as they are keen to start the implementation of the solution.
Preparation
As PM your first task is to assemble an evaluation team. These individuals have got a vested interest in this particular vendor selection process and will consist of client and consulting representation. Once the team is assembled, you will then need to define the technical, business and vendor requirements which need to be documented, circulated to relevant teams for input and eventually finalised. These requirements will be used for assessment purposes during a later stage of the process.
Sample - Key Content for a Requirements Document
Vendor Search
The next stage you will now perform is a vendor search. Here you and the team will investigate and compile a list of possible vendors. Upon reviewing the candidates, you and your team would then select vendors to request more information from and this would trigger the writing of a Request for Information (RFI) which would be sent to selected vendors for a response. Once the responses are received, they would be evaluated and put on the 'Short list'.
At any stage of the vendor selection process and certainly given this project has an IT focus, as PM you would also invite the vendors in to demonstrate their IT solutions. This activity could be performed to help determine the 'Short List' or post short listing once responses have been received.
Sample - RFI Template
Request for Proposal (RfP) or Request for Quotation (RfQ)
The next stage is to write a Request for Proposal or Request for Quotation. These documents should include the following details and be issued to the vendors on the short list
Business Overview & Background
1. Detailed Specifications
2. Assumptions & Constraints
3. Upgrades/Maintenance
4. Testimonials
5. Terms of Business etc
Sample Software RfP
Proposal Evaluation and Vendor Selection
The main objective of this phase is to minimize human emotion and political positioning in order to arrive at a decision that is in the best interest of the company. As PM you need to be thorough in your investigation, seek input from all stakeholders and use the following methodology to lead the team to a unified vendor selection decision:
1. Preliminary Review of All Vendor Proposals
2. Record Business Requirements and Vendor Requirements
3. Assign Importance Value for Each Requirement
4. Assign a Performance Value for Each Requirement
5. Calculate a Total Performance Score
6. Select a the Winning Vendor
Sample Vendor Evaluation Template
Contracting
The final stage in the vendor selection process is developing a contract negotiation strategy. Remember, you want to "partner" with your vendor and not "take them to the cleaners." Review your objectives for your contract negotiation and plan for the negotiations be covering the following items:
1. List Rank Your Priorities Along With Alternatives
2. Know the Difference Between What You Need and What You Want
3. Know Your Bottom Line So You Know When to Walk Away
4. Define Any Time Constraints and Benchmarks
5. Assess Potential Liabilities and Risks
6. Confidentiality, non-compete, dispute resolution, changes in requirements
7. Do the Same for Your Vendor (i.e. Walk a Mile in Their Shoes)
About.com - Vendor Management Best Practice
TechRepublic.com - Vendor Selection Process
DecisionLens: Vendor Selection Decisions
TechSoup.com - Vendor Management Process
Axia Consulting - RfP Evaluation
For Retailer XYZ you have selected ABC Organisation as the preferred vendor and they have been contracted with to provide and implement the merchandising solution in conjunction with working with the client and your consulting organisation.
Planning Stage
During this stage, like non IT projects, planning would consist of producing a plan, baselining that plan, selecting the project management approach you wish to deploy, scope management, team design and mobilisation, work breakdown structures, setting budget and identifying resource requirements.
As the Project Manager and in consultation with your Programme Manager and Seconded Client Programme Manager you have devised the following project structure for your merchandising project.
For your project a 'Waterfall' approach has been selected which consists of 6 key stages of activity.
· Plan
· Analyse
· Design
· Build
· Test
· Deploy
These stages have to be completed fully and in the order shown (as demonstrated in the presentation). It is also important to finish one stage before progressing to the next. The Programme Board has requested a stage gating approach also where they want to make the decision at the end of each stage to assess its completeness before progressing to the next stage.
As this is an IT project, a number of key 'Workstreams' have also been identified. These workstreams form your horizontal phases of activity which cuts across each stage of the 6 stages listed. For the purpose of this project the following workstreams were identified:
· Application (including requirements gathering) Workstream
· Process Workstream
· Testing Workstream
· Training
· Organisation Design
· Technical Architecture
· Data Conversion
· Communication & Engagement
· Project Management Workstream e.g. status reporting procedures, risk management procedures, change request procedures etc
For the Retailer XYZ case study the following workstreams will be reviewed in detail throughout each stage of the project:
1. Project Management Workstream
2. Application Workstream
3. Testing Workstream
For each workstream at each stage of the Project lifecycle, key principles, considerations, processes and templates will be provided.
As the Project Manager you will be responsible for the Project Manager Workstream. You have also identified a fellow consultant Chris Smith as the Workstream Lead for Application and a seconded team member from the Client, Jane Harris, as the Workstream Lead for Testing.
Planning : Project management
As the Project Manager for the Merchansing Project you are to lead the Project Management workstream. You are currently in the planning stage of the project and need to consider, populate and get eventual sign off for a range of deliverables and processes.
Your role as Project Manager is to also drive the project forward, manage issues, make decisions, be forward thinking, co-ordinate the communication of key messages, solve resourcing complaints plus many manage many other planned and unplanned situations and scenarios.
On the agenda for this stage are the following deliverables and processes:
· Defining Stakeholder Analysis and Management processes
· Defining the Project Team Structure and Team Composition
· Defining Risk Management processes
· Creating a Project Plan & Budget
· Creating Project Specification (Project Charter or Project Initiation Document)
To complete all of the above requires extensive involvement from the various workstreams you have identified, the ABC Organisation and the Client. Close and regular contact with those workstream leads is essential to ensure the processes and deliverables are as rich in term of content as they can possibly be.
Stakeholder Management & Project Roles
So you are new to the project, new to the client and you have to make a good first impression - where do you start? Stakeholder Management is key. Stakeholder management is the process of managing the expectation of anyone that has an interest in a project or will be effected by its deliverables or outputs. By engaging the right people in the right way in your project, you can make a big difference to its success.
As PM, you will be managing stakeholders from the client, from your consulting organisation, from the 3rd party vendor, the immediate team, those impacted by the change to name but a few. Stakeholder Management although defined during planning will need to be managed during every stage of the project lifecycle. You also need to be mindful, given the length of the project your stakeholder group will change. As stakeholders leave, get promoted etc, new stakeholders will be introduced. It is your job as PM to pick these new individuals up, share knowledge about the project and engage with them to understand their attitudes towards the project. Also bear in mind the most supportive stakeholders are not necessarily the stakeholders you need to concentrate on fully; remember the unsupportive, stakeholders with a negative attitude can do far more damage to the success of your project. These individuals need to be brought on side and managed carefully.
Risk Management
Risk management is the identification, assessment, and prioritization of risks. Risks are potential situations which could turn into issues for the project that may have a negative or positive impact (typically the former).
For risks, like stakeholder management this is a process that cuts across all stages and needs to managed throughout the duration of the project. For your project key risks that have been identified include:
· Resource availability
· Financial Stability of 3rd party vendor, ABC Organisation
· Dependenies on other projects e.g. integration with warehouse management project and the planning project
· Project Complexity
Project Planning, Resourcing & Work Breakdown Structures
So why does the Retailer XYZ project need a plan? Why not start to execute immediately?
A plan fulfills many roles including:
1. Clarifying scope, resources and budget
2. Specifying all activities, scheduling of resources, risk identification, communication management
3. Makes the enstire project visable to the team
4. Identifies activities in which delays impact on the total project
5. Used for variance analysis (target v actual performance)
At this stage your plan will be high level. As you and your team progress through the subsequent stages and your knowledge of what is required to do becomes more refined, more detailed plans will be produced.
Retailer XYZ used MS Project for the planning activity. The reasons for this included the functionality to baseline the plan, add and track resources, show dependencies between project workstreams, show the overall programme plan for the client in relation to merchandising, warehouse management system etc. The baseline plan was then used to track variance (progress against plan) as the project was executed.
Project Specification (Charter or Project Initiaiton Document (PID)
The project specification or PID is an essential deliverable for the project and needs to be produced during the planning stage. The PID is a well proven concept borrowed from Prince2 and aims to achieve the following for a project:
· Statement of purpose
· Scope statement and objectives
· Milestones
· Cost/time estimates
· Stakeholders
· Project management individuals, roles and structure
· Project risks
The PID is the final output for the Planning this stage and requires input from all your Workstream Leads, the client, the 3rd party vendor and any key stakeholder. In your case, the PID took several months to achieve final signoff and went through many iterations. To ensure success, your project must have a PID in place and be formally signed off. It would have been a catastrophe to have started the project in earnest without a PID in place.
Planning: Application and testing
Your Workstream Leads are as follows: Chris Smith is responsible for the Application Workstream, Jane Harris is responsible for the Testing Workstream.
Application Workstream
The Application Workstream will focus on understand the capabilities of the solution, determining system requirements, identifiying any enhancements to be made to the solution and identifying any underlying problems or bugs found with the 'vanilla' product. The Application Workstream's primary goal is to ultimately make the solution work for the business. Close client and ABC Organisation involvement and management is also essential here.
The Application is central to the success of the project and this workstream will need to be involved in many areas of the project. For example supporting training prep (Training Workstream), understanding how the system impacts processes (Process Workstream), writing functional designs for enhancements (Testing Workstream) to name but a few example.
During the planning stage your lead will be planning a key activity called the Conference Room Pilot. The Conference Room Pilot is an opportunity for you, the client and the vendor to get into a room and go through each facet of the system to understand how the solution works, what needs to change, where the gaps are, what processes need to change, where are the integration points with other systems, is the reporting functionality suitable etc. More details will be provided in the 'Analyse' stage for this workstream.
Testing Workstream
The Testing Workstream will focus on the testing activities associated with the IT solution, guiding the project through unit, system, integration, user acceptance, regression, volume and performance testing. All of which requires:
· a testing strategy
· a test plan,
· resourcing plan
· test environments sourced and created
· test and fix processes/templates determined.
We will take a look at some of these areas:
A test strategy is an outline that describes the testing approach of the software development cycle. It is created to inform project managers, testers, and developers about some key issues of the testing process. This includes the testing objective, methods of testing new functions, total time and resources required for the project, and the testing environment.
For Retailer XYZ the 'V' model of system development will be used; this in turn drives the testing strategy.
The V model supplies us with an ideal development mode that can help us understand the relationship among different software development phases. The V-model was originally developed from the waterfall software process model. The three main process phases - requirements, high-level design and detailed specifications - have a corresponding verification and validation testing phase. Implementation of modules is tested by unit testing; system design is tested by integration testing; and finally operational testing verifies from the requirements. The V-model gets its name from the timing of the phases. Starting from the requirements, the system is developed one phase at a time until the lowest phase, the implementation phase, is finished. At this stage testing begins, starting from unit testing and moving up one test level at a time until the operational testing phase is completed.
Additional Resources:
· Test Strategy and Test Approach
· Regression Testing vs Retesting
Case Study: Analyse stage
For Retailer XYZ, the Analyse Stage of the project will involve each workstream refining their understanding of their respective area. As you become more knowledgeable and familiar with the task at hand, those highlevel plans produced during the Planning Stage start to become fine tuned as you and the team gain a greater understanding of the project and the potential challenges. For the Project Manager this stage is where 'execution' of the project begins. The need here is to implement robust project management processes to support delivery of the project. For the Application Workstream Lead this is a critical requirements gathering phase and a conference room pilot will be neccessary. For the Testing Workstream Lead this stage is about preparing for future testing cycles. This will involve training your team in the vanilla solution, planning in more detail each testing stage and setting up the necessary infrastructure e.g. test environments with solution implemented, setting up test and fix processes and tools, learning about the client business. This stage is about analysing and researching the change between the as-is organisation and the potential to-be organisation in relation to size, complexity, degree of impact and cost to achieve the change. Next Steps: Continue to the sub-sections: Analyse - Project Management Work stream and Analyse - Additional Work streams.
Analyse: Project management
So you have reached the end of the 'Plan' stage with some key deliverables such as the PID now being signed off. What you now need to consider for Retailer XYZ is how to co-ordinate the efforts of the various teams under your direct management, ensure they adhere to the baselined plan as closely as possible and establish clear channels for communication. It is now up to you to define a number of essential proccesses and create the relevant templates.
The key processes you need to develop and roll out at this stage include:
1. Status Reporting from your immediate team
2. Status Reporting to the Programme Manager and Programme Board
3. Issue Management
4. Budget Tracking
Please remember you still have your stakeholder management and risk management to manage during this stage!
Status Reporting (from your Workstream Leads)
For any project manager, one of the keys to success is communication. As PM you will have 4 routes of communication: up to your stakeholder, horizontally to other projects and your peers, downwards to your team. In terms of communication downwards, and receiving communication back from your workstream leads, status reporting is key.
You have communicated to your Workstream Leads that it is mandatory each Monday for them to attend a status update meeting where a weekly agenda is set and progress, issues, risks for the project/workstream is shared. Here key decisions are made, and any news from the Programme Board or Programme Manager can be communicated. It is also mandatory for all Workstream Leads to supply a status report by close of play Friday, the week before the Monday status meeting. The template would include progress to plan, workstream issues, resourcing requirements and A.O.B (any other business).
Status Reporting to the Programme Manager and Programme Board
In addition, as PM you will also need to keep your Programme Manager and Programme Board aware of progress or slippage of the project and any major issues that require their input and decision on.
The Programme Manager for Retailer XYZ has also requested that you attend a weekly status meeting for Project Managers and asked you to populate a similar status reporting template. In terms of communication to the Programme Board, you will attend a monthly board meeting to share news.
Issue Management
As with any project there will be a high volume of issues raised by the team, other projects, client, programme manager etc that you will need to document, track, prioritise, allocate, escalate and ultimately resolve. The status reporting process will generate a high volume of issues. To track these issues an Issue Log is essential and a weekly review cycle has been determined.
For Retailer XYZ issue review is incorporated into the status reporting procedure.
Budget Tracking
There are 3 key elements a PM should track during delivery of the project: time, quality and cost. These form the 'Iron Triangle' and need to monitored as the stakeholders will track these entities very closely. It is therefore in your interest to track the spend on the project. Costs can come in many forms and may include:
· Resource (People) e.g. consulting staff vs contractors vs client vs 3rd party vendor staff, UK or overseas, experts or generalists?
· Facilities and Equipment e.g. office space, meeting rooms, computers, printers
· Expenses e.g. travel, accomodation, launch events, conference room hire
· etc
For Retailer XYZ financial analysis has been requested from the Programme Manager on a monthly basis and as PM you will monitor this on a weekly basis.
Analyse: Application and testing
Application Work stream
As mentioned previously, your colleague Chris Smith will be hosting a 'Conference Room Pilot' to determine with the client and ABC Organisation how the system will work and what additional enhancements they will want to make to the system.
Key deliverable/overview are included here:
· Conference Room Pilot Prep/Plan/Templates:
· Running a Conference Room Pilot
· Developing a ‘Conference Room Pilot&rsquo
· Requirements Template (used as a key input into the CRP)
· Modification (or Enhancements) Resource Estimates:
· Estimating Software Enhancement Projects
Conference room pilots will be held to take the requirements and processes of the client organisation and compares the solution to these to determine the 'gaps'. These gaps could consist of missing functionality and reporting, complex integration needs, process amendments etc. Once these gaps are identified, they are prioritised and there are many tools to help you achieve this. Once example is MoSCoW which stands for must, should, could and would:
· M - Must have this requirement to meet the business needs.
· S - Should have this requirement if possible, but project success does not rely on it.
· C - Could have this requirement if it does not affect anything else in the project.
· W - Would like to have this requirement later, but it won't be delivered this time
This activity is essential at this stage as output from the Conference Room Pilot will provide input into training e.g. additional funtionality/reports to include in training, testing e.g. any new functionality will need to be thoroughly tested, data conversion e.g. understanding the clients IT landscape will help determine some of the conversation activities, change management e.g. who will be impacted by the change, how will their roles change etc.
Testing Work stream
For the Testing Workstream your colleague, Jane Harris, will be looking at creating testing environments, creating testing processes & templates, creating scripts for testing of vanilla product, securing intense training on the product, analysing the application architecture to understand scope of integration testing, reviewing the user requirements to help shape user acceptance testing.
For an overview of test scripting go the Compendium Developments website.
Case Study: Design stage
During the design stage of your project for Retailer XYZ, the various workstreams will be shaping/designing how their repective areas will be developed and delivered. It is at this stage that key findings from the 'Analyse' Stage will be used to as a key input into decision making for the 'Design' stage.
Some of the key design decisions for Retailer XYZ were as follows:
· For the Training Workstream should the business go for online training, train the trainer delivery (whereby key clients are trained in the solution and then they deliver to the users), traditional training (whereby the consulting company trains the user groups), who should be trained in what e.g. training needs analysis
· For the Technical Architecture Workstream how many servers to support the IT needs, how many databases, where should they be located, can we offshore, what network capacity is required
· For the Data Conversion Workstream how 'clean' is the data, what is the mapping between old system data and new system data, how many routines will be need to be written for automated conversion
Design: Project management
As the PM during the next 3 stages of Design, Build and Test your role is to manage the 'day to day' running of the project.
You will be focusing on achieveing the 'Iron Triangle' components to ensure the project is on time, within cost and delivers a fit for purpose solution. To achieve this you will be maintaining and executing the processes you defined in the previous stages: stakeholder and risk management, status reporting and communicating progress or slippage across workstreams or the project as a whole to the Programme Manager and Programme Board, capturing, escalation and resolution of issues, dealing with resource issues, carefully managing change requests, tracking project spend, analysing resource burn rate, working closely with the 3rd party vendor and being forward thinking with regards to planning the next round of activities.
These next 3 stages are full of uncertainty and challenge. Here you will have to demonstrate not only your managerial skills but your leadership skills as you will need both to guide the project to a successful conclusion.
Design: Application and testing
Application Workstream
During the design stage, for any IT requirements these will be taken and assessed in terms of effort to develop, complexity etc and typically a functional and technical specification will be produced. These design specifications have to be as detailed as possible given that these designs will be handed over to the third party, in-house software engineers or contractors to build and test. The design will need to be signed off and version control is a must. It is also essential to involve the client in the design stage to ensure buy-in to the proposed solution. For Retailer XYZ, they have requested a substantial change to the system to accomodate their fashion lines. This represents change in every facet of the solution.
Specifications will be required for all system changes to the vanilla solution. These changes could be in the form of (but not limited to) the following:
· reporting enhancements
· new/changes to existing screens/fields
· new/changes to existing interfaces
· configuration around security
· branding of the solution
· new functionality
· updates to the Help feature
As PM, you have also requested 'Design Walkthroughs' need to be included. Design walkthroughs are one of the most powerful quality tools that designers can leverage to detect defects early and take steps towards continuous improvement.
Key deliverables at this stage include:
Functional Specification:
How to Write a Functional Specification Template for Functional Specifications
Technical Specification:
How to Write a Technical Specification
Testing Workstream
For the Testing Workstream this is an intense time for preparing test scripts and expected results for a range of testing to be carried during the 'Testing' stage. As mentioned previously your colleague has to plan for unit, system, integration, regression, volume and performance testing. Each stage requires its own unique range of test scenarios, test scripts, set up of environments, client involment, close working with the 3rd party vendor and in particular close links to the Application Workstream as all the system oriented enhancements will require testing.
Key deliverables at this stage include those reflected in the 'Analyse' stage for the Testing Work stream
Case Study: Build stage
For all workstreams 'Build' represents the physical creation of the key deliverables.
For the Training Workstream this involves creating the training guides, for the Data Conversion Workstream this involves creating the data transfer routines, for the Technical Architecture Worksteam this involves building the servers and the network.
For Retailer XYZ as an IT project the focus is not just on the build of the solution itself, the scope is much broader than that as indicated above.
Build: Project management
As mentioned previously for the 'Design' stage of the project, as PM you will be managing the 'day to day' of the project.
Close monitoring of the 'Iron Triangle' elements of time, cost and quality solution will be necessary throughout. Any variance to any of these 3 factors will require an action plan to get the project back on course and achieve a successful outome.
All essential project management processes from status reporting to stakeholder management continue in earnest throughout this stage.
Build: Application and testing
Application Workstream
Build is when the actual coding of new requirements commences and will be based on the signed off scripts from the 'Design' stage. The build could be done in-house or outsourced to a software vendor or contractors. Technical environments would be required for the build to take place within. Version control is also key here for the code. For Retailer XYZ, a number of contractors have been sourced and are on site to support the development of the new system requirements.
Testing Workstream
During the 'Build' Stage unit testing is often tighly linked with the build of any new code. Here your colleague, will be using the unit test scripts to work through a series of unit tests and outcomes recorded. If the outcome is successful then testing can continue, where an error is found a SIR (system investigation report) would need to be logged so that a 'fix' could be worked upon - Retailer XYZ used a specific testing recording tool to support this activity. Once the fix has been applied to the code, retesting would then need to be performed.
Case Study: Test Stage
For all workstreams involved in the Retailer XYZ Merchandising Project, the Testing Stage represents an opportunity to test out deliverables prior to deployment. Again this is not limited to just testing the solution and the associated enhancements or system changes.
Simulations of data transfers from the old systems to the new could be trialed in a 'development' environment for the Conversion Workstream, the client would be involved in providing feedback to the Training Workstream on the training materials produced so far and for the Process Workstream new or changes to existing processes will be walked through with the client to ensure robustness and buy-in.
This is a critical stage like all the ones prior, however, success here depends on whether the business and the project team has confidence to move towards a potential 'go-live' and progress to 'Deploy' stage.
Test: Project management
As mentioned previously for the 'Design' stage of the project, as PM you will be managing the 'day to day' of the project.
Close monitoring of the 'Iron Triangle' elements of time, cost and quality solution will be necessary throughout. Any variance to any of these 3 factors will require an action plan to get the project back on course and achieve a successful outome.
All essential project management processes from status reporting to stakeholder management continue in earnest throughout this stage.
Test:
Application Workstream
This team will now be deemed the 'experts' of the solution and their understanding will need to support many of the other workstreams in completing this stage. In particular, this team will support the testing workstream in system, integration and user acceptance testing with the client. It is also critical for this workstream to support the Training and Process Workstreams.
User Acceptance Testing is where scenarios are developed that are business oriented and the client ia given the opportunity to walk through the solution and test it out. As with all other forms of testing, scripts and expected results will be documented and actual results recorded. As PM, you want the client to walk away from this exercise having had a positive experience.
Testing Workstream
As previously mentioned the Testing Workstream have used a V-model stage-gating approach to work through merticulously each stage of testing as indicated in the diagram:
Unit Testing and some system testing would have been covered during the 'Build' stage. On reaching the formal 'Test' stage all the other forms of testing now come into play but in a strict order as shown. Again this is where all the test scripts, expected results, actual results, SIRs, Fixs, retesting takes place in a dedicated environment.
For Retailer XYZ, it took 9 months of intense testing to go through each level of testing successfully.
Case Study: Deploy and Support Stage
This is when all aspects of the project 'Go-Live' and will be rolled out in a logical order or in parallel depending on whether dependencies exist e.g. training will be rolled out prior to the system going live as the new users will need to know how to use the system. As PM you have built into your plan that a 'Business Readiness' assessment is performed prior to go-live to ensure you are confident Retailer XYZ is in the best possible position to receive the new solution along with all the new processes etc.
Given that this is a software implementation you will also need to provide a period of support post implementation but also promote knowledge transfer to the staff and help desk so they can continue to support the new solution as it transitions from project to a 'business as usual' solution.
For go-live you will need to decide when is a logical go-live date/time? Will you roll out a department at a time or implement 'big bang' where every department moves to the new system at the same time?
With any project there is no guarantee of success and a 'Contingency Plan' will be necessary. Will you decide to run on the new and old systems at the same time? What happens when something goes wrong? How will you know? How will you roll back to the old system? It is essential to create a contingency plan and communciate this to your team and the client.
In closing the project you need to produce an End Closure Report which needs to be signed off with the key stakeholders including the Programme Board. This report will outline (from the original PID) the original scope of the project compared to what has actually been delivered. It is also at this stage you complete your project lessons learnt - How would you do things differently? What went well?
Some of the key deliverables at this stage include:
· Business Readiness Assessment:
· Go Live Checklist
· Go Live
· End Closure Report
· How to Write a Closing Report
In conclusion the implementation of the merchandising system, the warehouse management system and the planning tools were successful for the actual client. The programme took 2 years to complete and did involve a major UK software vendor. Based on the success of the programme, the consulting organisation remained a key player in supporting the client with the acquisition of a range of new stores and implementing the necessary infrastucture to realise the client's strategic objectives. Although the programme was a success it was by no means a straight forward programme to be part of and we were faced with many challenges and difficult times.
The learning from this .... each project is unique, full of 'unknowns' and variety but that is what makes project management and the role of project manager so interesting and a fascinating place to be.
End of Unit Activity
Using your knowledge and understanding acquired from the previous units (1 - 7), describe and analyse 3 differences between the basic project management principles covered to date and practices demonstrated in the IT case study. Your word limit for this activity is 1000 words.
