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]1 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