I'm not sure who the audience for this is supposed to be. Just like the blog entry I left about adding a battery holder to my 1990s era MIDI workstation, I think it's mostly just a sounding board, and notebook for myself. Maybe some of the people who work on this project will read this, maybe not. Anyway, it's a lot of words, and not a lot of specifics.
Just got off a meeting, kicking off the third phase of a project that I've been working on for 22 months. This is the phase where I hand off management to someone else, and I stay around to help .. answer questions, but mostly try to stay out of the way. Enable confidence in the person taking over, instead of deference.
I asked for someone else to take over. Partly, because the next phase deals with databases that are not directly in my management chain, and partly because two years on a single project is starting to burn me out. My final phase isn't quite over, but it is quickly coming to a close.
22 months ago, I was named as the delivery manager, and a handful of the best engineers we could gather came together in St. Paul to kick off a major change to the way our databases accept and distribute data changes out to products. The project started with some very lofty, but loose goals, and in two weeks, we all turned those goals into requirements, and from requirements, we came up with a fresh framework ... a fresh approach. We all scattered back to our corners of the world, and further refined the plan. I did my best to break down the approach into the smallest possible chunks, and estimated the overall project at 24 months.
Management, stakeholders, development team managers and developers further refined the project plans, and did everything possible to squeeze down the timelines. Eventually, we were approved to start with an unheard-of 18 month plan for phase 1. Projects rarely get approved if they cannot complete in the current fiscal year. But the goals are strategic, and everyone in the management chain above me did their best to sell the benefits.
I remember reading a very-long time ago that most software projects that are estimated at more than 1 year of work ultimately fail. I took this to heart, very early, and have always done everything in my power to take this project in small parts.
This project is something that I'm extremely proud of, and I brought the first phase to completion within 2 months of the original 18 month goal. Through these related software projects, the database that was updated has seen an amazing doubling of delivery times, without an underlying hardware update. Plus opening up possibilities for many new projects. Not all of the original lofty goals could be met, but this project leaves us in a fully functional state where the roadmap to those other goals are obvious.
As phase 2 started, without any time to really sit back and figure out what to improve from phase 1, I started making notes about all of the side projects that had come up. Legacy things we had to fix, and get out of the way to make the new software succeed. Without the benefit of doing those side projects BEFORE phase 2, I'm starting to see some of the same dependency delays in phase 2, as I had in phase 1.
With this phase 3 kick-off, I have presented these side projects as pre-requisites. Individual stand-alone projects that can be completed within the older infrastructure software that will make the conversion to the new software a lot easier.
Now that phase 1 is done, and I've really had time to dissect the things that could have been better, I think the separation of those parts, those sub-projects, should have been more formal, earlier. Teams ended up specializing on each project, but there was a /lot/ of places where cross-influence was not controlled in a formal manner. Frankly, I think that I was lucky that there was no part of the process that went wrong while my attention was on something else. Lucky that the team is so mature, and that there are plenty of senior developers who understood the goals and the principles that were set out for this project.
Make no mistake. Failures happened in phase 1. Major failures in design that could have caused some potential major service issues have had to be flagged and fixed. There were team members who put in some extremely serious hours fixing things ... sometimes because my own advice was followed and wrong. Yet, despite the set-backs, the team succeeded.
As phase 2 wraps up, I'm taking this time to look back on what was accomplished, and hope that we continue to see successful completion of the future phases that I now pass on to my colleague.
In a very real way, I'm also sad that I'm handing this off to someone else. Yet, I know that there are new challenges to lead, and I'm anxious to help figure out what's next.
Just got off a meeting, kicking off the third phase of a project that I've been working on for 22 months. This is the phase where I hand off management to someone else, and I stay around to help .. answer questions, but mostly try to stay out of the way. Enable confidence in the person taking over, instead of deference.
I asked for someone else to take over. Partly, because the next phase deals with databases that are not directly in my management chain, and partly because two years on a single project is starting to burn me out. My final phase isn't quite over, but it is quickly coming to a close.
22 months ago, I was named as the delivery manager, and a handful of the best engineers we could gather came together in St. Paul to kick off a major change to the way our databases accept and distribute data changes out to products. The project started with some very lofty, but loose goals, and in two weeks, we all turned those goals into requirements, and from requirements, we came up with a fresh framework ... a fresh approach. We all scattered back to our corners of the world, and further refined the plan. I did my best to break down the approach into the smallest possible chunks, and estimated the overall project at 24 months.
Management, stakeholders, development team managers and developers further refined the project plans, and did everything possible to squeeze down the timelines. Eventually, we were approved to start with an unheard-of 18 month plan for phase 1. Projects rarely get approved if they cannot complete in the current fiscal year. But the goals are strategic, and everyone in the management chain above me did their best to sell the benefits.
I remember reading a very-long time ago that most software projects that are estimated at more than 1 year of work ultimately fail. I took this to heart, very early, and have always done everything in my power to take this project in small parts.
This project is something that I'm extremely proud of, and I brought the first phase to completion within 2 months of the original 18 month goal. Through these related software projects, the database that was updated has seen an amazing doubling of delivery times, without an underlying hardware update. Plus opening up possibilities for many new projects. Not all of the original lofty goals could be met, but this project leaves us in a fully functional state where the roadmap to those other goals are obvious.
As phase 2 started, without any time to really sit back and figure out what to improve from phase 1, I started making notes about all of the side projects that had come up. Legacy things we had to fix, and get out of the way to make the new software succeed. Without the benefit of doing those side projects BEFORE phase 2, I'm starting to see some of the same dependency delays in phase 2, as I had in phase 1.
With this phase 3 kick-off, I have presented these side projects as pre-requisites. Individual stand-alone projects that can be completed within the older infrastructure software that will make the conversion to the new software a lot easier.
Now that phase 1 is done, and I've really had time to dissect the things that could have been better, I think the separation of those parts, those sub-projects, should have been more formal, earlier. Teams ended up specializing on each project, but there was a /lot/ of places where cross-influence was not controlled in a formal manner. Frankly, I think that I was lucky that there was no part of the process that went wrong while my attention was on something else. Lucky that the team is so mature, and that there are plenty of senior developers who understood the goals and the principles that were set out for this project.
Make no mistake. Failures happened in phase 1. Major failures in design that could have caused some potential major service issues have had to be flagged and fixed. There were team members who put in some extremely serious hours fixing things ... sometimes because my own advice was followed and wrong. Yet, despite the set-backs, the team succeeded.
As phase 2 wraps up, I'm taking this time to look back on what was accomplished, and hope that we continue to see successful completion of the future phases that I now pass on to my colleague.
In a very real way, I'm also sad that I'm handing this off to someone else. Yet, I know that there are new challenges to lead, and I'm anxious to help figure out what's next.