We're of course a bunch of techies at NI and we love monitoring what's going on in the world. Hopefully these blogs share some of our interests. We have a beautiful audio room that's used for training and we've gone and made some podcasts on current technology. As of today, you can listen to essays on:
- Safety and Isolation
- What is Embedded?
- A PCI Express Architecture Overview
- Microsoft Vista Overview
- LabVIEW Architecture
Check em out.
I spent 8 years somehow managing software projects and it took years to discover a few secrets that made life easier. When it comes down to it, the job of a project manager is:
- Insure that the (task/product/thing) is delivered on time with the proper level of features and quality
- Insure that there is appropriate and correct communication between the team and others
That's it. The rest is just details. My best advice for a project manager is...
Do as little work as possible to accomplish those goals
After all, no one ships a project plan or a schedule. If the product ships correctly, you've accomplished your goal. Never get carried away with your own importance.
Some projects actually run themselves. You can do zero work and the project will meet the goals. But, there are cases when you need to do more than nothing.
- You have inexperienced or new employees on your team
- Your product depends on other products/components in development
- Your schedule is dictated by other products (i.e. something else is shipping at the same time and they won't wait for you)
- Other products depend upon your product and so a slip in your project will slip them also
- You have remote developers
- Features get inserted into your schedule midstream
- Each time your team crosses a size threshold (10, 50, and 100 developers) you need to change the way your team operates.
- The release date of your project has a large monetary affect
- Your developers are working on multiple projects at once
- Your product must be high quality (high expectations, life critical, is infrastructure other people depend on, etc..)
Many projects have these risk factors. So, you think "I need a tool to help me do this". You look up "Project Management Software" in Google and you get.... Microsoft Project. Let's talk a little about tools for second.
Project management tools are never the magic bullet they are advertised to be. They won't pull in a late project. They don't give you "the answer". They lie to you. They only work in conjunction with your brain.
They will, however, help you make sense of chaos and they will give you something to blame if you screw up. But I think the first is the only one that is valid.
So, what is the role of your brain here?
Rule #1 - Never trust a precise date.
If someone tells me a product will ship "March 25, 2004". I call BS immediately. No one can pinpoint a ship date down to the day unless that day happens to be tomorrow, and then I'm still suspicious. If you said "March", "First Quarter", or "Sometime in 2004" you would not only be more accurate but you also tell me something important: your level of certainty in the date and that tells me a lot.
So, the number one reason I dislike MS Project is that it only gives you dates with daily (or hourly) precision. It won't tell you "sometime in March" and thus it is lying to you. It's the lie of omission. The lie that makes you overconfident. I'd much prefer MS Project to tell me "I have no idea when your project will ship". That's really good information because it forces you to use your brain and go find out.
Rule #2 - Greater detail does not give you greater accuracy.
I learned this one the hard way. The schedules I created (in MS Project) for the first two years of my career constantly slipped. I went to training classes looking for the answer. I used to think they were off because I wasn't including enough details. After all, the schedule kept slipping because new tasks kept getting inserted. If I got more detailed, I'd know all of the tasks and my schedules would be more accurate. This happens to be 100% wrong because, at least with software development, you can never know ALL of the tasks. The best you can do is sketch it out and fill in the details later.
Instead, use the law of large numbers to help your accuracy. (The more things you aggregate, the greater your accuracy). I have no idea how long it will take to fix a particular bug. Could be a day, could be a week. However, you may learn from the past patterns of the team that each developer can fix, on average 2 bugs per day. So, if you have 60 bugs and 3 developers, it will probably take 10 work days to fix all of the remaining bugs. You are making an estimate but it will, in my experience, be very accurate. It also saves 60 entries in your project management software.
Rule #3 - Know the difference between unknown duration of known work and unknown work
Most software development projects are late because there's more work to actually be done or more stumbling blocks than you realize at the start. It's not that a particular task took longer to complete than you thought. It's because there was a bunch of other tasks that you never thought of or came up in the middle.
How do you deal with this? First, never make a schedule until you have scoped the work. This is not just because you need something to write down. Scoping the work forces the people involved to actually start figuring out what they need to make and that will force them to figure out how they are going to get it done. Now you have the "known work". I can't overstate how important this is. Upfront work now saves rework or mistakes or schedule slips later. I've seen it and I believe it. You can't have an accurate schedule before you know what you are doing.
The second piece of advice is the rule of 50%. It's my rule and it's based purely on experience. It may vary between projects, styles or whatever but I've found that even for a well specified project, there's about 50% more tasks there than you think there really are. This is the "unknown work". If I hear that there are 20 days worth of known work left, I can bet that they will be done in 30 days (20 days + 50% of 20 days = 30). If there are 6 months of known work left, they will ship in 9 months. And this isn't just a fudge factor. When doing scheduling, I count down the amount of work left, add 50% to it and that becomes my best guess at a ship date. In the past 4 projects, that date has been the closest thing to right. Since it's a percentage rather than an absolute, it stays accurate even as the amount of work decreases (and unfortunately MS Project can't seem to deal with that)
Rule #4 - No news is rarely good news
You can't adjust to problems unless you know about them. Engineers rarely volunteer that there are problems. They are problem solvers and so they try and fix the problem themselves. If you don't ask, they won't tell. Ask.
Rule #5 - Nothing is ever 90% (“almost”) done
This rule comes from a senior manager at NI. Progammers love to tell you that they are "almost" done. Internally translate that to "I'm almost feature complete.. That whole bug fixing, testing, integration thing doesn't count toward done.". So that means at best they are 50% done.
Making an Accurate Software Schedule
I didn't answer how to make a schedule because once you follow these rules, you're pretty much home. Use whatever you want. I use Excel. SW projects are not usually dependency driven. There is a list of tasks, you estimate a particular amount of time for each task, add in the conversion factor for meetings and other overhead (i.e. usually double the task estimate), account for unknown work (the rule of 50%), add it all up and you get a general target date. Don't tell anyone that date because it is wrong (see Rule #1). Give them the date +/- a quarter and you're probably being accurate. Update the task list weekly. Now focus on the harder things :-)
Whenever you are in someone's office and you see a stack of magazines, don't hesitate to look at the covers and see if you like the headlines. Call it "desk surfing" rather than "web surfing".
I stumbled across an article called "Presentation Lessons from Comedians" in the an older issue of IEEE Computer magazine. It had a lot of good advice that I think can help people be better presenters. Granted, some people just have "it", that personality feature that allows them to be captivating speakers. Some people don't have "it". But, if you follow some of this advice, you will be less likely to put the audience to sleep even if you don't have "it".
- Have a purpose. Decide what you want to tell them before you make a single Powerpoint slide. Make sure what you want to tell them is only 2-3 things. If you can't summarize what you want to tell them in 2-3 sentences, you're trying to do to much. Most of your talk is purely about supporting those 2-3 things.
From the article
"...if you get your story right, the delivery will follow.... [When] the story isn't clear, the audience has to work too hard to make sense of it, and they will resist it, become irritated, and finally lose confidence in the presenter. Conversely, once the story is clear, the audience will come along for the ride even if the presenter [isn't a gifted orator]."
- Beat them over the head with your purpose. Don't put up a lot of data and expect them to infer what you want them to leave with.
- Leave a lot out. There's plenty of neat tidbits of information floating around in the world. Leave it out. Some of your audience will care, most will find the first 3 amusing and then get bored.
- Be brief. The worst sin in speaking is to go long.
- Know your audience. Know what they are expecting to get out of the talk. If they are expecting you to talk about something else, they will fixate on waiting for a particular piece of information and not focus on what you are trying to tell them
- Never read your slides - not only can the audience read them while sitting there, they will feel like they should just leave and instead get the slides later (which they can read in 5 minutes rather than the hour you are making them sit there). Talk "about" each slide instead.
- The article had one I'd never seen before - Look people in the eyes. Don't focus over their heads, look straight at them. As engineers, I know we hate to make eye contact while speaking but this one has merit and I'll give it a try. The article states that you will get a much better read on the audience this way and it will force you to subliminally do things that actually improve your talk.
The final one I'll leave you with is
- Know your material. If you know the information, you'll relax. The worst talks I've given have been NITS presentations because someone else made the slides and I didn't know the material like the back of my hand. Please never ask me to give an Advanced DAQ talk again :-)
Technorati Tags: Speaking Presentations Engineering