A Checklist for software support teams.... for accepting completed software projects

Software Maintenance Acceptance Checklist
Assumption is that... software project-teams should handover scope-completed-solutions to long-term-support-teams; so support-teams can take over solution-upkeep from that point. Ongoing upkeep would include planned-maintenance-activities, bug-fixes, new-enhancements, ongoing –customer-support etc.
  

Project teams are expected to leave behind a stable, scope-completed product release. But, the problem is that... project teams often sneakily leave a chuck of unfinished work for the long-term-support-team to work on.
  

This is a checklist… to assist support-teams; when accepting software projects. Show this to the project manager as early as possible; so that the project can prepare for this checklist.

[This is not a project-closing-checklist to assist project teams. This is a product acceptance checklist for maintenance teams; so that maintenance teams can evaluate what they are accepting] 

Maintenance Acceptance Checklist

Check Description
Initial Checks
Maintenance roles and individuals identified and documented. Lots of projects start without paying attention to a long term support needs. Force the project to identify support personnel and budget. Project should identify roles and individuals needed to support the system after the project (from IT, Business, Vendor etc.). Also, make sure the business owners understand their ownership responsibilities. [sample support roles: IT manager of product, operations staff, help desk, issue resolution and bug fixing, business administrators and super users, business owner of product, how long will the original project team will be able to answer questions, vendor support etc.]
All need artifact repositories are defined. Projects should have defined repositories for documentation, code, training material etc. This is to ensure that project is not planning on transferring an unorganized, half done set of deliverables.
Maintenance team is allocated enough time for training. Make sure that the new team is actually allocated enough time to get trained on this new product. Allocate time for training... not just accept the product last minute.
Project Development Lifecycle related checks
Project Vision/Scope/Business Need/Success criteria is clearly documented and signed off by sponsors. Project should have been created to accomplish certain goals. Project should have documented these objectives and received approval from sponsors. A clear understanding of these original objectives are important, when further enhancing the solution or answering ongoing business questions. Is the project charter still valid?
All Stakeholders are clearly identified. Make sure you get a decent stakeholder analysis. So you know who all the players are and how they were engaged. This knowledge sometimes does not get transferred out of project teams. Get a good understanding of who is business, IT and vendor that are playing a part in the success of this product.
Business Analysis Documentation is complete. Project “Requirements” should be clearly documented; so, the support team can continue with the original understanding.
Testing related documentation is complete. Project should have various testing documents. Procedures and test-cases to test a new release, test-cases for a quick smoke test etc.
Requirement Traceability Matrix (RTM) is complete. Project should have a mechanism to map requirements to provided functionality.
All required environments are available.  Make sure the project gives all needed environments (development, test, training etc.) to continue supporting the solution. If not, you will be spending time and money… either putting together environments or inventing work-around processes.
Training and training documentation completed Make sure the project has completed all training (users, helpdesk etc.) and transition management. If not more effort to do that.
Relevant service levels are understood and signed off by business and other stakeholders. Business needs to understand the agreed support level; downtime, recovery time, recovery point, planned maintenance windows etc. Other relevant teams (network etc.) need to understand their commitment to the solution health.
Customer roles and responsibilities are defined and understood by customer. Customers and business managers sometimes do not understand their ongoing commitment to the product.
Vendor related items are documented and handed over. Are there any vendor contracts, commitments, contact #s.
All required licenses are understood and procured by project. Many projects create a solution forget the licenses needed for post project development-tools, business-user-connectivity etc. [Licenses like… Hardware, software, application CALs, database CALs, third party software, annual-maintenance-charges etc. for all environments])
Solution in Production Related Checks
Solution is stable in production. Many new deployments are not stable; and maintenance-teams unofficially end-up putting extra unplanned hours stabilizing the solution. It is good to officially identify the effort needed to fix the problems projects leave behind. Is the system stable under full load?
Application monitoring (reports, logs, start system, stop system, verify system health etc.) tools are complete. Can the application be monitored?
Common support procedures accepted by maintenance team. If the project has not documented these, you will end up doing the work eventually.
Further change-deployment-process is clearly documented and accepted by maintenance. Maintenance team needs to understand how to properly push new releases to production. Make sure the process is clearly documented.
Disaster recovery and redeployment is clearly tested and documented. Need to understand how/when/point to recover the system in a disaster.
Business continuity plans and procedures are identified. What is the plan, if the system is not available for two days?
Production issue resolution and escalation process is defined. Need a clear process to handle/escalate issues.
“Customer Support/Service” process is well defined. Is the process of listening to the customer and providing appropriate feedback defined?
"Expected-Maintenance-Activity List" completed and accepted. Project should build a planned-maintenance-activity list. This list states what activities, agreed service-level and effort that is needed for future upkeep of the product. This should be the actual tasks and effort expected from the support-teams to maintain the product… so you can later compare this baseline estimates to reality.
Official Unfinished Work
Pending risks accepted by Maintenance team. Maintenance team should understand all “identified risks”; so that the team can plan for downside.
Pending Issues accepted by maintenance team. Maintenance-team should understand pending project issues that are not resolved. Because you are on the hook to resolve them.
Known bugs are understood and accepted by maintenance team. Get a grip on current bugs. You will have to either fix these soon... or provide work around processes. If there are too many bugs, complain like there is no tomorrow.
Road Map of next steps accepted by sponsors, customer and maintenance. Projects often leave behind a secret list of promised future enhancements. Make sure everybody understand what that list is.
“Benefit Realization Review” process is clear. Are there reviews that need to be done to evaluate the project success in 6 months etc. Who is supposed to be doing them?
Project Team Sign-Offs (appoint leads as assessors of their areas)
Project Manager has signed off on project solution quality. Get the project manager to officially say that the project is ready to be transferred to the support team.
Business Analyst Lead (Product Management) signed off. Get the lead of the business analyst side (whatever it is called in the project) lead to sign off that the solution actually satisfies the business need.
Development lead signed off. Development lead is responsible for quality of all development artifacts.
Test Lead signed off. Test (Quality Assurance) is ultimately responsible for signing off a working product..
... Based on the project, follow all leads for official sign off. Lead of Architecture, Security, Training, if there is a user-experience group etc.
Final Checks
Solution accepted (signed off) by customer. Make sure the customer is actually happy with the solution as scope complete. If not, more unplanned work for you.
Solution accepted by other relevant IT teams. If there are other relevant IT teams, make sure they all have accepted the solution (Help desk, Network team, Security team, Architecture etc.). Team list may depend on the project type.
All “Personnel and Budget” needed to maintain the new product is determined (and approved). To not take ownership of yet another product without a proper funding plan.
Maintenance-team trained and ready to accept the new system. Someone from maintenance should Sign off that the maintenance team actually got trained.
Maintenance-team have no issues or concerns. After training, maintenance team still may have concerns. List them with effort needed to address them.
Final versions of all project collateral accepted by maintenance team. Make sure that the maintenance-tem is happy with all needed supporting components (documentation, source control, deployment scripts, proper business introductions, service-level-agreements, disaster-recovery-plans etc.).
Sign-off this document. Get a manager to sign off that this list is actually accurate.

All this is… so that maintenance teams will not end up having to complete a half-built solution. And for management to understand that project-team actually left a product not fully completed.


To be practical…

1. Create your version of the “maintenance acceptance checklist”.
2. Show the list to project managers early… so they know what your support acceptance criteria is.
3. Identify the core support team early, and try to embed some in the project; as support quality control.
4. Actually follow through completing and signing off of the list.
5. Identify area leads (activity or feature) in the project, and appoint them as assessors of that activity. Get them to sign off their area. This will put validation responsibility back on the project.
6. Even if you are forced to accept some incomplete line items for practical or political reasons, a list will bring attention to incomplete line items... as “additional-effort-needed” by maintenance-team.
7. Do this, even if most people from the project team are assigned to maintain solution; to ensure a quality project completion.
8. Monitor and compare planned-maintenance-activity list (provided by project) against the actual activity and effort the support teams have put in. This will help improve future support effort estimating.