As I noted previously, I have moved from the world of development over to the world of project management (among other things). And, as I continue to learn and hone my skills in this new world, I will post my thoughts, experiences and observations here. My first project was a small project with one of the developers on my team. Essentially, we needed to tweak an existing application to take into account a new process that had been implemented recently so that it would handle the new format of the data. So, along that line, I did what I have always done in situations like this. I scoped out the requirements from the user end and then mapped out a solution before taking it over to the developer. A fairly straightforward process with which I am familiar and should have enabled me to hand it over to him without any major issues. The solution that I had mapped out was how I would do it if I were developing it. The problem, of course, is that I was not developing it and instead of being able to hand over a set of guidelines that accurately explained the issue while giving the developer the leeway to implement a solution to the best of his skills, I was dictating how he should do his job. I realized it midway through my first meeting with the developer when we were reviewing my documentation to ensure that he understood the requirements. And as soon as I realized it, I recalled my own feelings in the past when I had been the developer in that situation. “Tell me the problem and what needs to happen and then I will fix it!” Instead, I was doing what had been done to me by other project managers and analysts in the past.

To his credit, the developer did not point out what an idiot I was being. And when I realized what I was doing, I stopped immediately and apologized, explaining to him what I had done and that it was not my job to tell him how to do his. I think he appreciated that and we then discussed some of the ways that he could approach a solution. Now, normally I would not think a project manager would have to get into those details but I was curious to see his thought process and wanted to be able to contribute if I could. As it turned out, he had a solution that was pretty similar to my own thoughts with one exception where he found a more efficient method of handling one part of the process. In the end, he was able to build what was needed with a minimum amount of oversight on my part and little in the way of the sort of frustration that we have both encountered in the past. We had a solution on-time, on-budget (in this case, meaning it didn’t take longer than we’d originally anticipated and thus no need for extra time/money) and something that did what the users wanted. We were both praised for our work on this project and everyone was happy. And for my own part, I learned what it means to step back from something that I didn’t need to do and allowed the developer to do what he does best – develop a working solution.

It is worth pointing out that Alex Ullrich has also recently talked about something along this same line about limiting the developer and is worth reviewing as well. And Eli (aka Tarwn) also wrote an entry that covers a larger scope of projects and how to ensure they’re done (correctly). Both are a little more comprehensive and certainly well worth a read