Change Management and Innovation: How a leader can effectively communicate change initiatives and enco
Leading a change initiative can be a daunting task. You may have to deal with great resistance from your staff and need to look at ways of managing the change so that it empowers staff not threatens them. One way to spark enthusiasm for change is to encourage creativity and innovation including looking at incentives to reward great ideas or solutions to problems.
Do your team members react to change initiatives well?
Change in the current economy is a fact of business. To compete on a global scale, businesses have to be willing and able to change with changes in the market. Employees that can adapt to these changes easily without resistance will keep the climate positive and motivational. How the changes are communicated to the team is the key element. When a change has been decided by upper management, ask for the team’s input on how the change should be implemented. Empowering them to find creative solutions to managing the change will ease the adaptation.
Are team members innovative and creative?
When a problem arises, are creative, innovative solutions suggested or do they stick with the tried and true. Innovation is highly important to market competitiveness. Like any creative process, innovation needs to be nurtured, explored and supported by open communication, resource allocation (sufficient time, brainstorming space, necessary ingredients/supplies, budget) and a climate that allows for calculated risk taking. Allow the team to learn from here mistakes and encourage having a plan B.
Are You Considering Outsourcing?
A business bids for and hires a company, like a consulting firm, to build a software solution to meet a business need. The software product being developed by the consulting/contractor firm will be used by multiple employees from their individual PCs. The software involves employees entering raw data that will result in calculations and reports that feed into other business processes.
During the progress of the software development, various employees (users) of the future software product decide that they would like various calculations performed differently than originally specified, or the want additional entry tools designed into the software. Instead of going through the company sponsor or the PM, the end-user (employees) goes directly to the software developers and or other project technical team members and press for the changes or alterations to the project. The project team member feeling either generous or wanting to do a well-meaning favor goes ahead and incorporates the change to the design and begins altering the software code. This results in rework of a previously completed tasks, costing extra money in man-hours and adding time to the schedule. One of the other software team members finds that the new change has made part of the work they just completed unusable and now has to make corrections to accommodate the well-meant earlier change. By this point, the design specifications are no longer accurate to the contracted functionality. What also happens, left unchecked, when one end-user gets to talk a project team member into making a change that doesn’t get routed through the change control process, another end-user will, inevitably, do the same thing, or the first end-user will continually approach the development team with multiple changes.
In the end, the contracted company that is building the software solution finds themselves on a runaway project train that is attempting to deliver a product far out of scope and (unless the customer is willing to accept all the unapproved costs) eating away the profit margin, eventually leaving the contractor to eat all the over budget costs. The consulting/contracting company that is running the project may find itself losing money on the deal. The buyer winds up getting something they did not bid on. The consulting/contractor and the purchaser/customer end up in a battle over the cost overrun, blown project schedule and a final product that doesn’t meet the original contract requirements.
Bottom Line: The project team must be on the same page as to how changes will be processed and managed. When a project is bid out and a bidder selected, the contract is for a set amount of money for a very specific product or service with very specific specifications and a defined project scope. Every change or alteration has the potential of costing the project in terms of money and time, as well as quality of the outcome. Not every request for a change is in the project, customer, or user’s best interest. A PM must be vigilant in monitoring changes and potential risk to the project. The PM needs to avoid being the bad guy: explain the situation to the sponsor or contract office and recruit them to help rein-in the end users. The PM will also need to re-baseline the project scope, cost and time or performance variances will have little value towards determining the health of the project.