Managing the Project
September 22, 2000
7:43 a.m.
I was eating lunch with some friends. We were all huddled around with our fried rice and our General Tso's Chicken and whatever. People's conversations were reverberating around us. I had hot tea. Chopsticks were in hand. "I could never be creative at 4:30 in the morning," one said. Everyone laughed. "Well," I replied sheepishly. "I look at it this way. The really stupid thing would be to get up at 4:30 in the morning and NOT be creative."   We're working on a fairly big project at work. The guys are translating business requirements into technical requirements, and I'm writing a simple little HTML-based prototype to show business people what we heard from them. (I haven't forgotten, William--we're just running a tad behind where I wanted to be, par for early concept development I suppose). It's all pretty cool. The developers are turning into a fine team. Progress is being made. The problem I have, though, is that this is a stage of the process where there are really no big milestones. It's all a bunch of parallel efforts that are running together. It's all discovery and organization. It's adding clarity. Once the clarity is arrived at, then milestone happen. Remember--process is everything. Putting implementation before understanding and architecture is a dangerous thing in a development project of any kind. I, however, like milestones. Deadlines are motivators for me. Deadlines are their own reward. Set a milestone, meet a milestone. Set a goal, meet a goal. All good stuff. It's like digestion. When things are going well for me, I'm processing milestones, ticking things off, moving forward. So this time period of every development phase is when I get most uncomfortable. Yes, I have schedules. But the process takes whatever the process takes at this point. The milestones are there to provide urgency. But that's all. See how my mind works?--or maybe the way my mind doesn't work is the more correct way of phrasing that. Stories work for me just like the software development process, though. I manage them in my mind the same way as I manage and direct a software team. Software development, by the way, is quiet a creative endeavor. A good leader has deadlines. A good leader drives his people to achieve them. A good leader understands quality over schedule every day, yet knows that all he can manage is schedule. Quality is a property of the realm of skill and understanding and time allotted to complete. A good leader always concedes to quality, but places goals to ensure productivity. A team rises to meet goals, and feels good when it knows it has achieved something important. So a good leader uses deadlines and functionality goals as his toolset. He backs off goals that turn out to be unachievable, but presses others to make his point. When I sit down to write, I am my own project manager. Today, I completed a major milestone. Version 0.1 of this story is complete. I didn't really think I could complete it this week--but my project manager set this goal for me. If I hadn't hit it, I know him well enough to realize he would have let me slip. But I didn't need to ask him to do that this time, and I'm pleased with myself. It's something under 8,000 words. Now I need to work on v0.2. Maybe in a few days it'll be ready for beta release. Sometime later it'll be ready for production. Think about it. Trust your people. Trust yourself. Set big goals. Have a great day.  So, like, where's your gantt chart? Daily Persistence is © Ron Collins |
|
Crossing my fingers for Lisa Silverthorne ... |
BACK TO 
|