Lessons learned on an acquisition project

28.08.2015
Several years ago I was managing projects as an employee for a very large Fortune 500 engineering and aviation firm. They were in the process of selling off one of their business units and the process was being led by a contract application developer. The developer was basically filling the role of project manager as well because everyone thought the process from a data side was just to get them some electronic drawings out of a database as well as a few thousand data records -- something that required some code to be developed and some data to be delivered on DVD.

The contract developer -- and the company -- soon realized he was in over his head and they asked me to take over. How I stepped in, though, was probably not the best way to handle it. I learned several things that apply to how best to take over a project and also how best to handle an a-typical project -- an acquisition or sell-off project -- like this.

Kick off the transitioned effort. Yes, it’s a real project. It may not seem like it if you’re used to managing technical projects from beginning to end, but taking something like this over mid-stream that has been experiencing “management” issues needs PM attention…and that should probably include a mini project kickoff. At least that’s the lesson I learned. I jumped into the same chaos that the contract developer was excused from. I should have treated it like a real project from the start – it took me a while to learn that lesson and I lost time and it cost money in the process.

Create a real scope. Basically, find out what "done" will really look like. If you don't do that, then you may never be done. And for this effort - to my organization - done meant getting that final $250,000 installment of the buyout price. But the end target kept moving and I was never going to get us to the pot of gold if I could never get them to agree that we were done. The customer - the buyer of the business unit - kept asking for different data each week. Obviously requirements were weak and I didn't take the time to sit down with the customer and redefine those requirements. Unfortunately, I had just picked up where the other guy left off thinking everything was defined well enough. It wasn't. And it wasn't until I halted the effort and had them sit down and come to a consensus on what everything was that they needed and what "done" would look like – only then was I able to see the light at the end of the tunnel and direct everyone toward that. That we could make real progress toward done and official sign off.

Create a real schedule. This goes back to treating it like a real project – which I didn’t at first. I thought I was just overseeing the transfer of a few electronic drawings and some other data items. That turned into a request from the buyers for all configuration data, for all environmental test data, for a couple of test databases delivered on DVD, etc. It seemed like a never-ending process and I had no schedule created to go against. Big mistake. Doing it over again I would have created a schedule Day One and worked with them on that schedule from that point forward. That’s what I eventually did…after I had learned my lesson.

Conduct regular weekly status meetings. I conducted adhoc meetings, but not the formal weekly status meetings that I swear by. Mistake. Again, this was a result of me thinking this was a short-term effort and would be done in a month. Reality is that it took close to nine months to actually complete and I had to involve our legal staff and others in the process. What started out as me working with the buyers of the business unit – and the personnel that were transferring with the sale – ended up including many, many more people on the project team. Treating it like a project with regularly schedule status meetings would have avoided lots of chaos. I eventually got there, but it took me a few months before I realized that it wasn’t going to end until I took that control and incorporated those best practices.

Get sign offs on everything. Finally, get signoff on everything. Anything that passes from one party to the other on an effort like this basically becomes a deliverable. You need to document that you completed that requirement and delivered that data. I did that – but much of it was after the fact. By the time the effort was over I did have all of the necessary signoffs in place, but it took a considerable amount of backtracking on my part to get those signoffs. Treat it like a project from Day One…that was my biggest lesson learned.

Summary / call for input

How about our readers Have you had an irregular project – perhaps something like this that you thought was short-term and very different from other projects you managed, only to find that had you treated it like a real project from the beginning life would have been much easier Thoughts Please share and discuss.

(www.cio.com)

Brad Egeland

Zur Startseite