September 17, 2008 at 9:17 pm
Comments posted to this topic are about the item The Release Schedule
September 18, 2008 at 6:43 am
You're having this problem because Project Management hasn't implemented a proper communication plan. I see this problem on a lot of projects. Everybody is sending every e-mail to everybody, and there are IM's flying around, and there are meetings like crazy... So there's a lot of noise, and it's distracting, and the really important stuff isn't getting communicated properly at all.
When I was a software development manager at a six billion dollar company (that I won't name) I used to get 400+ e-mails a week. 400+ emails. And I was in meetings 80% of the time. And people would send me IM's asking if I got the e-mail they sent.
If you can't control the noise, you'll never get anything done. A formal communication plan may sound like big brother trying to restrain your creativity, but if it's done right it has the exact opposite effect. A formal plan sets out things like:
Every morning at 9AM there is one meeting, where the manager comunicates important things to the developers face to face. That's where you go to find out what's going on. You don't have to hunt for it. All the questions get asked in one place. For this to work, the manager can't call a tactical emergency crisis meeting of the whole department everytime there's a minor stumble, and the manager has to be prepared for the 9AM meeting every day.
Developers communicate electronically amongst themselves using IM.
Changes in the design are communicated via e-mail and approved at the 9AM meeting.
And so forth.
It's like when you're driving, and you turn the volume down on the radio so you can see better... Cut back on the noise, and know where the important touchpoints are going to come from, and this problem is greatly lessened.
September 18, 2008 at 7:40 am
Interesting editorial, Steve. Reading between the lines, I think you’re saying project updates and meetings should be more focused to the relevant individuals. I agree with that part, but what I don’t agree with is the idea that we should be asking people for critical things right around the time we need them. While “hurry up and wait” can be annoying, “I need this one-week project by tomorrow” can cause a project to fail altogether.
By the way – I have to say that I love the picture that accompanied the article. Do you have any source information? I’d love to get a blowup of it.
September 18, 2008 at 7:57 am
The photo is from the EDS "Herding cats" commercial - from a Superbowl game a number of years ago. If you haven't seen it, you have to watch the entire clip!
http://www.youtube.com/watch?v=JWymXNPaU7g
p.s. Very interesting editorial. I like arobbins comments about formal 9 AM meeting.
September 18, 2008 at 7:58 am
I'm honestly not sure what I want. There has to be a balance between too many meetings and too little information.
For the deployment guys (production, operations), going to a morning meeting every day doesn't work. It's a waste of time. Same thing for clients, but they have to be informed at some times. I agree they shouldn't have things sprung upon them, but if we have a 3 month project, let me know once a month if we're on schedule, or just update the deployment meeting once a month. Then as we're two weeks out, touch me once, and then again right before.
For the client, which is me right now, I don't want to hear about every change, nor do I want questions every day. At the same time I don't want developers making too many decisions about the final ergonomics without me, so there does need to be coordination somehow. I'm looking for ideas.
The idea that there's one way to run a project is wrong. You communicate with developers in one way, operations/support people in another, clients another, management another. Developers both have to be insulated so they can work, but also in contact with people to get feedback, it just needs to be balanced somehow and I was hoping for thoughts on how you decide what that balance is. Same thing for clients.
The image I grabbed from http://philliptoutant.wordpress.com/, but it was just a google search on "herding cats". Lots of those images out there 🙂
September 18, 2008 at 8:23 am
I can see that on a large project, with a lot of developers, a 9 AM quick "stand-up" meeting to summarize important information is an efficient way to make sure everyone is on the same page, especially during the most intense development phase.
I am currently on an intra-institutional project that is getting close to testing the first release. We have a 2-hour meeting twice a month with all interested parties, including the "client" from elsewhere in the institution. The agenda is well-organized to keep track of and review outstanding issues, as well as demo recent progress/changes. What I like about the meeting is that the "outside" client and other interested parties attend and offer their perspectives. The meeting may seem long, but at the end, everyone knows any changes to priorities. The project manager follows up with meeting notes and a check list of tasks.
September 18, 2008 at 9:14 am
It's human nature, our brains can only handle so many threads at a time, so we default to assume certain things are unchanged unless we notice something different. Rather than fight human nature, we need to cooperate with it, when updated documents are circulated, plainly highlight JUST the new or changed material. Don't copy everyone on every detail. Not only will less mistakes occur, but workers will be more comfortable.
Interestingly organizations that WANT people to mis details when they change credit card terms, software terms, etc. take advantage of that with long paragraphs, with differences only visible with word by word readings.
...
-- FORTRAN manual for Xerox Computers --
September 18, 2008 at 9:28 am
I think the key problem here relates to the flattening out of the management structure within the company beyond what is efficient.
The most important task a supervisor or mid-level manager has is the effective coordination of the business unit being managed with the other parts of the organization. A good supervisor or manager shields the workers from the noise, filters the requirements out, and makes sure the goals are prioritized sensibly, whether from upper management or customers; in addition, the good manager is responsive to the needs of management and customers so that the right information/output is provided at the appropriate time.
In small companies, and in many large companies who are trying to follow a small company paradigm, there are no more intermediaries, or several management functional areas have been combined so there is no longer an intelligent filtering process. Yes, you can have too many layers of management, but you can also have too few - resulting in a lot of noise because everyone needs to find a way to get what they need directly.
In BizSpeak this is often mistermed "empowerment".
September 18, 2008 at 12:51 pm
arobbins (9/18/2008)
Every morning at 9AM there is one meeting...
A 9 AM meeting every morning? I'd quit that job. In fact I have.
I think the company should get rid of that manager, who would obviously have nothing to do if they weren't calling a meeting every day and screwing around with a Gantt chart that has dates on it that are no where near accurate.
Instead, I'd hire a couple more testers.
Joel Spolsky, http://www.joelonsoftware.com/, has posted several blogs on and around this topic. In fact, in his latest post, "Stack Overflow Launches", he talks a little about the development of their latest web site and even mentions that they had WEEKLY status phone calls, and has even recorded them in podcasts!
September 18, 2008 at 1:43 pm
I'd also recommend 37 Signals to check out. They have an interesting blog.
I heard Jason Fried speak recently and he talked a bit about how they build software and their philosophy. One interesting note he had about Gantt charts. He doesn't think they work, they don't model reality, and they're an abstraction he doesn't believe in. So he'll never add them to Basecamp or any of their other products.
September 19, 2008 at 8:25 am
Gantt charts don't work because the time frames are simply guesstimates that are wrong more than they are right. A Gantt chart can be good for an overall view of the project but as time frames change, the chart become too difficult to change and use.
I use a Gantt chart to plan out my entire year so I have an idea of what's coming. It can also show holes or gaps that may be able to be filled in. It's not 100% but nothing is.
Timely communication is something we should shoot for but is nearly impossible to achieve. How does a project manager know when to bring certain people in? They're not developers or DBAs. They may not really know when to bring them in. The best way I saw work was bringing us in at the point where the initial schedule is developed and let us tell them how much time we need to do our part. That way we have input into the schedule timelines and are held repsonsible for our part.
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply