If you were a rapper from the dirty south and you decided to make some cash on the side by working as a business analyst, what would you call your consulting firm?
Crunktional Requirements.
(I apologize.)
As I mentioned a while back, I've gone from a straight-ahead development role to more of a project management and development role. It's been an interesting challenge thus far. I do mean all shades of the word interesting there; from 'my life would be easier if I ran away and joined the circus' interesting to 'yay, we're having fun' interesting. Why such the range of experience? Well, it's because I've been exploring the solution space and I've made a lot of mistakes.
By solution space, I'm referring to a term that describes the range of possible solutions for a problem. The solution spaces between development and project management are vastly different. Let's say you get a lot of complaints from the users who claim that sorting is too slow in your application. As a developer, what are your possible solutions?
1. Debug the sort, isolate any inefficiencies and correct them.
2. Replace the sorting algorithm, leaving everything else in place.
3. Remove the sort feature.
Those are only a few solutions; you could expand that list several times. Conversely, let's take the same problem and approach it from the guise of a project manager.
1. Get together with Bob, tell him his sorting algorithm sucks.
2. Get together will Sally. Tell her that you don't think Bob is smart enough to fix his sorting algorithim. Ask her to fix it without telling anyone.
3. Get together with Bob, who wrote the sorting algorithm. Discuss the issue with Bob. Convince Bob that this issue is worth addressing. Get Bob to give you a time estimate. Double Bob's time estimate. Shift the rest of Bob's due dates back to allow time to fix the sort problem. Get Bob a spec for the change. Allow Bob to make the change, then test it to measure the improvement.
The first two methods would particularly good if you wanted Bob to punch you in the face or place a dead skunk in your office. Just like with the developer list, there are loads more solutions there. However, unlike the developer list, it's not just you and the problem; it's you, everyone else, and the problem. You can't solve the problem in code; you have to solve it in collaboration.
To me, that makes project management hard. You can't debug people (well you can, but you have to ask really nicely). There's no axiom that says once you've made three compelling arguments, a developer must go along with your suggestion. That's not to say that it's harder than coding. The solution space is just a little bit different.
Recently, I've been going through a transition at work, as I go from a pure development role to a project manager/development role. When I was first presented with the opportunity, I was gung ho. "Hell yeah, I'll do it," I said, "software is software, and the more I'm involved, the better the end product will be." I say a lot of idiotic things in the course of a day. They range from the mildly moronic (I wish someone made chocolate toothpaste) to the nearly braindead (I'm going to put a leash on the cat and walk her around the neighborhood). I think I may need a new classification for my initial statements about project management. Perhaps there's some level of stupidity somewhere, maybe a "Paris Hilton discussing quantum mechanics" level, that could house my comments because they were that absurd. Allow me to explain why.
I have an analogy. Assume you're a great cook, and that people come from miles around to indulge in your mango chutney. Now assume that your superiors discover this, and they come to you and say, "Listen, you've proven yourself to be competent when it comes to making food and you seem to have a pretty good head on your shoulders; we'd like you to consider being a farmer. If you can make the food, you can make the ingredients." Now that'd be a strange conversation. However, moving from development to project management is very similar. In development, your focus is on the final product; in project management, your focus is on the ingredients that go into the final product. It's a completely different mind-set.
Back to the farmer thing. If you're a farmer, you hold very little influence over your crops. There's nothing you can do directly to make a carrot grow faster or more enjoyable to eat; you personally can't improve the process of photosynthesis. All you can control is the surroundings: give it good soil and plenty of water, and keep the insects away. Once that's been set, hopefully the carrot can grow.
I've only been doing this for a few weeks now, but I've come to discover that's the way project management works. If you're unhappy with the code or documentation coming from the developer, you can't just throw yourself in there and say, "Let me fix that for you!" Coming from development, that's a huge temptation. Instead, you have to tweak the surroundings, like your design process or the amount of training that developer's received in that area.
Development is hands-on; the most important phrase is, "I can do that." Project management is hands-off; the most important phrase is "How can I get you to do that?" It's not solving problems as much as it is getting people into positition to solve problems. It's taken me a while to grasp this, but I think I'm beginning to come around.