Team to the Center..

It isn’t exactly what it seems..  About 10 years ago, my team implemented one of the first fully virtualized computing environments on a defense oriented platform.   It was a pretty complex system with a 4 tier architecture.  The software that we were sharing for end user productivity was called TeamCenter Requirements.

When our team realized what it was going to take to make this system work as an enterprise level capability that was available worldwide to users as far as Korea, we knew that our plan to get us the capability we needed were going to take imagination.

We needed a robust operating capability that had a good responsive speed of service, available to DoD architects, planners, and engineering oriented teams.    We needed to meet DoD security requirements and function on DoD infrastructure.   We were constrained by budget and we had an aggressive agile like schedule.  At the time, the concept of Agile development was not even something we heard of.

Fast Forward

AND.. We did it!  Our team pulled it off! … But what happened next is why this story is important.

Now that it works.. Take it all apart..

We had to transition the whole enterprise solution to a cloud based platform and as we moved all of our software and licenses, we quickly found out that the IaaS platform that we were moving our software to was not going to be enough to hold up the building.

We had to transfer equipment and licenses and…

After months of work it was done but the level of effort was so great that the team supporting the cloud platform was fed up and frustrated and they left.  Yes, they quit!  Our team had to essentially take over the work which mean’t they all had to shift to other companies and  it was a mess.

After a while.. they got frustrated and they left.. and what they left was explicit documentation (limited in scope and instruction).  The systems and support services were lacking and there wasn’t enough man power to support their capabilities no less the system that we brought in.

 Last man standing..

I went from a team of over 12 people down to just myself.  During the transition process I was pulled into a different project and I was no longer managing the system work.    I watched as the team left for other projects, one by one.  Now leadership came to me at the end when they had no one else and said “what do we do?”   When they initially asked me to work on the other project it was for a good business purpose and I understood, although I loved my team and I felt close to them.    Now they had shed everyone for one reason or another, they still needed the capability and they needed help.

Unfortunately, this project was under budget constraints that did not allow for new hires.. and they needed to maintain a capability for as long as possible without bringing in new people.   That is 12 down to 1 in support.  We did have a few people left on the cloud side of the house supporting virtual technologies but no one that understood TeamCenter except for me.

 

Black Box –> End of Life

1. Created a virtual set of appliances using the existing software.
2. Created documents to support the effort.
3. Defined some operating guidelines.
4. Set expectations on performance.
5. Came up with a transition plan.

Eventually,  the capability was replaced.  The work was able to continue and all of the staff involved had a successful transition.

 

Lessons Learned

1. People are not as replaceable as advertised.
2. Knowledge Management must occur over the long term and the life of a project.
3. When shifting project ownership, the incoming PM should maintain and grow KM.
4. Trust is key and when it is broken, your staff will leave you.
5. There are methods to convert and maintain a “Black Box” solution but they are all stop gap measures.  (Triage over a long term resolve)

If you have questions on specifics, please reach out!