Closing on Poorly Contracted Projects

I was once asked to help with a large transformation program at a fortune 500 product development company. They had outsourced several IT security transformation projects to a vendor. The contract was very poorly written, more assumptions than deliverable were listed, the deliverables listed were not measurable and there was too much loose information. The projects which were supposed to take six months each ended up taking three years.

 

I was faced with one of two options, spending dozens of hours sifting through project change requests, meeting minutes and status updates for three years' worth of work, or come up with an agile, fair, and meaningful approach to close on the project. Luckily, I was provided a punch list that a former project manager in the past had felt was all the work items missing. The punch list helped me make the decision to choose the latter option and follow an agile approach to close out on the project. I followed some simple steps;

 

1. Setup weekly punch list calls
2. Defined my role and the objective of the effort
3. Went through the list each week
4. Compared to the original contract
5. Identified any gaps

 

These five steps might seem straight forward, which they are, except when you have two teams, one representing the client always asking for additional items which are mainly operational enhancements and not project deliverables; and another team which is the operational team on the vendor side fulfilling these requests, not realizing that they are also playing a role as the project vendor team. This is the crux of the complexity. It is not that the projects were not closed out, and not in production, they were indeed open projects, but the work delivered is well in production use for years, with new teams on board from both sides and now people are not considering the original baseline or expectations, they are comparing with the day before. It was a continuous bleeding scar for both companies.

 

So the trick in closing these projects in addition to the agile process above was assertiveness, clarity, separation of duties and the ability to act as a mediator and setting a clear measurable deliverable for each open item, with the confidence to act as a business analyst or contract manager specifying the measurable deliverable as needed on the go.

When its Time to Close a Project, Close it

It's in the best interest of the project, its sponsor, the team and the business to close a project when work is delivered and value is realized. I have come across several instances where the client feels the urge to keep the project open for one reason or another. Here are common cases where project teams keep the project open.

 

• Waiting for a new feature in a future COTS product release
• Few minor defects not fuly resolved
• Extra funds are available
• It will be hard to get approvals for a new project
• No guarantees that team members will be available in the future

 

None of these reasons are legitimate reasons to keep a project open. Open projects are like potholes, they only accumulate trouble until they get out of control and then need a complete removal and replacement with a new project. If the business value has been delivered, close it, move on and start a new one if needed when the time comes.

 

What is an IOT Platform

IOT Platforms come in different flavors and capabilities. IDC defines an IOT platform as follows:

 

• connects to and manages IOT endpoints
• ingest and process IOT data
• visualize and present IOT data
• builds and hosts IOT applications
• integrates IOT data into existing applications

 

Do you have a different definition?