The Technology Project Life Cycle: Lessons Learned

Tony Laska, SVP-CIO, BrickStreet Insurance

Tony Laska, SVP-CIO, BrickStreet Insurance

Do you ever wonder why certain statements are made regarding the technology process and/or team within an organization? Here are a few issues we’ve probably all encountered during the project life cycle, along with a few helpful hints to solve them:

The project idea is initiated by the business teams. It’s taken to the executive team for approval, and the executive team approves the project. The work starts and no one can agree on the approach; the project teams struggle to get started and the executive team can’t understand why there is a delay.

• I’ve found, all too often, the executive team gets a high-level presentation of the value the project will bring to the organization. In theory or concept they all agree. However each functional team may differ on the execution. Avoid the confusion by taking the time up front to describe the approach. Your project teams will be better served to execute if they know which path to take.

• Leaders have to give the direction, which managers and individual contributors then execute.

The project is approved and the project team needs to be formed. In creating the team we need to remember:

• The project manager is not the project owner or sponsor.

• Business initiatives are not IT-only projects.

• Collaboration is essential; we have to remember “we all work for the same company, not just a department within the company.”

• A good person may not be able to do the job. Get the right resources.

• If you use a third party/vendor to help, they are an extension of your team and not a scapegoat. The organization manages the vendor; the vendor doesn’t manage the organization.

Time to start the work.

• Managers and project managers, be in the trenches with your team.

• Design the project with maintenance in mind.

• Trust your people to do their job.

• Be precise in your communications. Lack of precision means mistakes and rework.

• General premise: nobody comes to work every day and says, “I want to do a bad job”. Make sure the people are “in the right seats on the bus.”

• Once you commit, deliver.

The project is in full swing and the timeline is challenged.

• Search for the truth, understand project status. Know the difference between the big “D” (Done and no dependency) and the little “d” (my task is done but more work needs to be done by someone else).

• Find the hidden work. Tasks that aren’t associated with the project or project tasks to help others that delay the critical path items.

• Know who’s calling to request the hidden work. It may be a valid request.

• If you can’t deliver when you said you would, give ample time to adjust.

• Only go to the “well” once to ask for more time. Any more than that says you don’t have a good handle on the work.

• Test until you’ve got the major functionality clean and 80 percent or more of your issues resolved. The other 20 percent will drag on, so you have to make the call on when to stop and implement.

• The more time you give for testing, the more issues you will find.

• You’ll never find all the issues because the production user will do things you never expected.

• Be aware of “burn out,” the team will be tired but they will want to persevere. They are not sharp when they are tired and mistakes will occur. Give them work/life balance to keep them productive.

"Your project teams will be better served to execute if they know which path to take"

The project is ready for delivery.

• Plan for issues to occur and have the staff ready to respond.

• Bring people in before normal working hours to use the production system. This will flush out the obvious issues, give you time to correct them and have the system ready when the rest of the staff arrives.

• When issues occur, and they will, the faster you fix them, the shorter the organizational memory will be regarding the issue and success of the roll out.

• Remember if you have the “right” people on the project, no one has to remind them when something doesn’t turn out as planned. These people will have enough internal remorse and guilt for everyone.

• Use the challenges as learning experiences so they aren’t repeated in the future.

• Celebrate successes along the way and at the end. The extent of the celebration is dependent on the significance of the issues.

• Recognition, regardless of the significance of the gesture, helps build trust and an environment where people can do their best work.

Read Also

Making a Case for BPM to Process Sensitive Business Leaders

Victor Vizzuett, Director of Continuous Improvement and Project Management Office, AkzoNobel

Fostering Cohesive Change at the Lowest Common Denominator

Donald Kuk, VP-Global Business Transformation, BNY Mellon

BPM: Are You Driving Process Change, or Are You Being Driven by It?

Mia Leondakis, VP Business Transformation & Automation, VMware