Back in January 2001, we started looking into a migration to a Windows 2000 network. When I say "we," that' s a complex pronoun standing for eight to ten different administrative groups, each handling anywhere from
300 to 2,000 computers. All were independently responsible for their lines of business, but some spanned across lines of support. Others provided e-mailboxes but didn 't maintain the user accounts. And some even had big collections of Novell NetWare servers, which limit the Windows 2000 Active Eirectory arena tremendously. It was a terrific nightmare.
Well, we started out great guns. We formed a technical working group of technicians from admin areas that were interested in going forward with Windows 2000 Server. We came up with a lot of good initiatives: enterprise administrators who are strictly responsible for the root servers, strict limits on where organizational units could join the Windows 2000 forest, separate roots for test and production ("prod"), and so on.
We got off to a pretty good start, with regular meetings to talk about what to do next, problems we ' d run into, and technical issues that had to be worked out. People were anxious to get the root servers in place and begin nailing up domain controllers (ECs) and migrating users.
But we had a lot of problems with the test root servers. Progress on this went slowly—so slowly, in fact, that some entities got tired of waiting and began to put ECs into the prod root, even though it wasn' t ready! We were close to having a mutiny on our hands—people wanted to go! They didn' t want to go through more and more testing. The technical team disbanded.
Then we began testing the snapping-on of a EC. The administrator in this EC' s group installed the EC using rights from the root servers that we' d temporarily given him. He went in, took administrative control over some things, and delegated the Eomain Name Service (ENS) operation to his local server—in effect, causing all root servers to look at his box as the root ENS authority. In other words, this guy was a real cowboy.
We spent a couple of weeks exchanging detailed technical e-mails, trying to solve the problems. Finally, we determined that we couldn't fix this without reburning the test root—a delay that angered everyone. They were tired of all this test folderol and on fire to get their production machines operational.
Nevertheless, we reburned, with very little help from other administrative entities (who had previously been very willing participants). As the days after the reburn went on, we met with a lot of inactivity on the part of anyone, a lack of interest in going forward with the project. In fact, one entity was seriously thinking about detaching and setting up their own forest! This was plainly somewhere we did not want to go; it ' s not a good idea to have several Windows 2000 forests floating around, especially in an environment as small as ours.
We had never treated this project like a project. Oh sure, we got some technoids together in a room and talked out the details. We hammered out a very official looking document or two (or twelve), detailing the things people had to do in order to be a part of our forest.
But for all that, we didn 't know what our deliverable was! Not one person could identify it. We couldn ' t pick out the stakeholders versus the customers, couldn' t point out the sponsors, had no project plan, wrote no schedule. In fact, it was plain to me after a few minutes that our stakeholders thought they were customers—hence, if the Windows 2000 test root needed to be reburned, it wasn 't their problem.
We had what I call the "build a shed" project plan. If you' re going to build a shed, you kind of intuitively know that you need a hammer, saw, nails, some boards, and a tape measure. You may not think you need to work with plans. You hammer and saw away and, sooner or later, you have a presentable enough shed.
We reassembled the technical team, this time assembling it as a project team. We appointed a project manager, named the sponsors, and spent some time hammering out the details of the remainder of the work to get the roots stood up and functional, so that we could close out the project and get on with positioning specific DCs and migrating users. We did, after all, have the foundation of the house—we ' d already built two roots and had months of good, solid background to go on. We just had no confidence that the roots would withstand the production load we were going to put on them.
We came up with a fantastic project plan, replete with tasks, personnel assignments, and durations. We got permission from the sponsors (there were five in this case) to allow the technicians to spend a week together in a room hammering out baselining, testing, backing up, recovering, crashing servers, and going through all the good solid pre-staging of the roots we hadn't yet accomplished—all with a very aggressive timeline.
We crashed the project—we threw a bunch of technicians at it with specific tasks and short, hardcore deadlines.
You know what? We pulled it off. Today, the roots stand, the DCs are up, and people are working on their user-migration project plans. And everyone is a huge believer in the power of project management techniques to bring people out of the technical world and into the business of putting a thing together.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.