We gave you five foundational steps to plan for a successful construction software deployment – along with several tips and best practices in our two earlier blog posts. Now we offer advice on managing the rollout of your construction software deployment.
The saying in construction is “plan the work and then work the plan.” Software product and project managers need to do more than just put together a plan and expect IT to follow it. You need to manage scope, schedule, and budget just like you would for a construction project. Below is our advice on managing the process.
1) Keep the rollout small and focused
This was tip #2 on our list of best practices during the planning phase, but it bears repeating here. Resist the temptation or outside pressure to go for a big, top-down rollout. We have seen too many software deployments fail when VP-level stakeholders get involved and push a mandatory new tool down to users.
Change is a big scary beast for most companies. The more opportunity you give users to get their feet wet before jumping in will help build support. Stick to your plan for a small and focused rollout. Take a phased approach. Use early wins to build grassroots adoptions. Doing so will make your entire project smoother and more successful.
2) Leave room for customizations & enhancements
If you followed the advice from our earlier posts, you analyzed the needs of your stakeholders and documented your business processes as part of your planning process. But don’t assume your plan is final. It is important that you keep an open mind and listen to input. Let project teams shape the tool
Some of you may object and say that a project needs to be standard across your organization. Standard, yes. Rigid, no.
You want your users invested in the software you are deploying. The best way to do that is to give them the chance to make it their own. If a project manager cannot tailor a tool to their specific management needs, you will have a harder time getting your software deployment accepted across the organization.
And, assuming you did your homework during the planning phase, hopefully the system you are deploying is configurable and customizable down to the individual project manager level (like Construction Viz, our flexible construction project management solution powered by Microsoft SharePoint 2016).
3) Update your plan & requirements documents
Requirements are essential to building anything from an office building to an enterprise construction software solution. But requirements are not a one-and-done deliverable at the beginning of the project. They are living documents and are relevant throughout the entire life cycle of the system all the way through scoping, change management, testing, training, and implementation.
You should keep your planning documents up-to-date as scope changes occur. Use version control to ensure the developers and stakeholders are all working off the latest specification.
4) Plan for change
You will have changes. There is no way around it. Maintain a contingency allowance for changes. You can use an approach similar to the estimate contingency levels defined by AACE. The more defined the scope, the better the cost and schedule. Keep a change log and budget accordingly.
5) Schedule regular design reviews
IT developers often gather requirements and then go off to build in isolation. The problem with this scenario is that most IT developers do not know construction. And they definitely do not know everything about your organization and your needs. They could therefore misunderstand requirements and spend countless hours on meaningless items. Do not let this happen with your project.
Maintain regular design reviews with your developers. This gives you the opportunity to see what they have built to date, clarify requirements and questions, manage scope, and remove roadblocks as needed.
6) Don’t forget User Acceptance Testing
Software testing involves both Functional Acceptance Testing (FAT) as well as User Acceptance Testing (UAT). Your IT provider should perform FAT. UAT should done by your users and include the project SMEs and Champions (functions described in Step 2 of the first blog post in this series).
A thorough UAT will uncover issues that might not have been clear during requirements gathering or design reviews, so make it an integral step to both fixes and enhancements.
7) Avoid communication layers
There is a good chance you are working with different teams to build, host and deploy your construction software. For larger organizations, these can all unfortunately be different companies, a fact that can complicate communications and accountability. If you are not careful, it can even derail or delay your entire project and cause support nightmares down the road.
Mitigate this risk by ensuring that roles and responsibilities for the project are clear – especially if there is another company between you and the developer. Make sure you have a direct channel to those doing the work. Avoid unnecessary communications layers that can slow down information getting to those who need it.
8) Get a pulse from your users & stakeholders
Do not wait until the end of the project to survey users about their likes and dislikes of the system. Getting their constant feedback – and letting them know you are listening to their concerns – is essential throughout the process. You want to make sure that your project is meeting the success criteria you defined in your business case.
Send frequent updates to the users about new features. Build a community of users that have influence over the direction of the system. You will find that these engaged users may even help you uncover opportunities to solve challenges you did not initially foresee.
9) But they are still using Excel?!?
Here’s a common scenario: You roll out your new construction software system, but project teams are still using Excel. Don’t panic – your project did not fail. Let’s face it, Excel is not going away just because you roll out a shiny new enterprise construction management system. There simply is no tool that gives users the flexibility they have with Excel. And it is hard to beat Excel for one-off analysis and reporting.
Ideally your construction management software will integrate with Excel (Construction Viz leverages SharePoint for deep integration with Excel, for example). If you planned your construction software deployment following the steps and tips we’ve shared, your users should have everything they need to automate standard templates and track critical information.
Our advice: Embrace Excel instead of ostracizing it and your users will rejoice. Excel is a great proof of concept and prototyping tool. Let users develop Excel solutions to supplement your offering so you can further understand how they work and what information they use to manage. If your user base sees the value in their effort, plan for a future enhancement to your PMIS.
If you are just starting your planning for a new construction software deployment, be sure to check out part one and part two in this blog series. We invite you to let us know your organization’s experiences and share any advice in the comments below.
Thinking of deploying a construction project management solution for your organization?
We have helped our clients deploy Project Management Information System (PMIS) solutions to manage multi-billion-dollar construction projects. Our Construction Viz platform includes everything you need to manage your construction projects— document management, dashboards, reports, forms, workflows and more—in one place.
Contact us to get a free consultation to learn more about what Construction Viz can do for your organization.
You may also like: