What's on Mike's mind?

Read what's on Mike's mind!

Cialis online

Archive for the 'Project Management' Category

Reforming Project Mangement

Posted by Mike on 18th April 2005

I highly recommend Hal Macomber’s blog, Reforming Project Management. Click on the link and see if you can find these two items: (1) Ten Rules for Project Mangers and (2) Five Elements of a Reliable Promise. I especially like how Hal keeps turning us back to the basics of good communication on projects. It is so important!

Posted in Project Management | No Comments »

Different Thinking

Posted by Mike on 10th March 2005

It is interesting to observe how people think differently. I sent out an announcement at work today that linked to a couple of PDF documents related to a committee I work on. One of my coworkers remarked that the document that described the committee’s function was larger than the actual work output. He didn’t mean more pages, but rather more bytes. I never would have thought to compare the size of the documents. I evaluate them on the content.

This brings to mind an important concept. You need several people, working together, to discover really good solutions. It requires the freedom to think differently and to voice your thoughts. Unfortunately, most businesses do not work that way. Because of that, many good ideas are lost.

Posted in Project Management | No Comments »

The Care and Feeding of Old Systems

Posted by Mike on 28th December 2004

I have been waiting for a report on exactly what happened to cause the computer crash that has disabled Comair. I’m not particularly interested in the company, but rather the problem. Here is an article from The Cincinati Post, describing what happened.

Tom Carter, a computer consultant with Clover Link Systems of Los Angeles, said the application has a hard limit of 32,000 changes in a single month.

“This probably seemed like plenty to the designers, but when the storms hit last week, they caused many, many crew reassignments, and the value of 32,000 was exceeded,” he said.

Legacy systems will often contain such hard limits. Usually, they are buried deep in the code and sometimes no one knows that they exist. Any point where such hard limits exist must be discovered. A solution needs to then be designed for each situation. If you are a manager or a maintainer of such a system, it is your responsibility to do this. When you are questioned, just point out the Comair computer disaster.

Posted in Project Management, Software & Computers | No Comments »

Open Source Project Management Insights

Posted by Mike on 22nd November 2004

I just read an article on Groklaw about Andrew Morton’s Speaker Notes from SDForum. You can go to Groklaw to read all of it.

Here are some excerpts that I think are related to successful projects. (If you like them, read the whole article, as these are taken out of context.)

a huge project is really an agglomeration of thousands of small projects

With the success of the Linux Kernel, you can hardly argue with this approach. The better you break down the huge projects into manageable projects, the better your chances are for success.

I dislike private design discussions because it cuts people out of the loop, reduces the opportunity for others to correct mistakes and you just end up repeating yourself when the end product of the discussion comes out.

It seems like so much work to involve everyone in design discussions, but it is critical to the process of having a quality product. The more eyes you have, the better your chances that mistakes will be caught early. Also, with better participation in design, the more your team will understand the what and why of the work.

Contributors send their code submissions as source code patches to the relevant mailing lists for review and testing by other developers. The review process is very important.

This open source project places a high value on code reviews. The Linux Kernel is a very large project, but I think you would benefit from code reviews even in small projects. It is too easy to be blind to your own mistakes.

The preferred form of bug reports from testers is an email to the relevant mailing list. We go through a diagnosis and resolution process on the public list, hopefully resulting in a fix.

We do have a formal web-based kernel bug reporting system, using bugzilla. But the bugzilla process is one-to-one rather than many-to-many and ends up being much less effective because of this.

Once again, we see a public process. Here it is concerned with bug fixes. Project communication needs to be team communication. If you leave team members out of the loop, you just might miss out on the best solution. Also, how will your team grow, develop and understand, without seeing the issues and contributing to solutions?

The above quotes from Andrew Morton contain very practical advice for project managers. I can sum it up in a short statement. Communicate openly on the team, in a public manner.

Posted in Project Management | No Comments »