Thanks For Chiming In!

We’ve received a ton of great comments on previous blogs, and I wanted to highlight a few of the best.
On My Cure for Overambitious Projects, Mark W. writes:

Most people realize “Rome wasn’t built in a day.” As long as individuals feel that their input, requests, and concerns are receiving attention and are being listened to – and not just being brushed aside, ignored, or pushed off ad infinitum; if they know that what they want is in fact for the most part possible and doable – just not right now:

So true!  One of the benefits of some of the Agile methodologies is that not only do the users see functionality being added on a regular basis, but they also play a key role in sequencing new development.

In response to Are Your Error Messages Understandable? Doug Q writes:

It would be wonderful if error messages could go a step further (for those who are interested and click on “advanced details” or some such option.)

He goes on to suggest error messages could identify what’s wrong with the data entered to help the user solve their problem, and get information back to developers when necessary.  I think this is a great idea.

On Risk Management in Software Development, Bob K. suggests using Swim Lanes to identify risks in cross-functional communication/data flow.  He goes on to describe swim lanes:

The swim lane concept is one where each swim lane represents a function or department or division of a company. The lanes can also represent different companies. When information is transferred from one lane to another there is inevitably information that has to be re-transferred because it was not in the receiver’s required format, the initial content request was incomplete, the transfer schedule was incorrectly specified, etc.

Every time, in a project, there is an anticipation of data or information transference (especially across a swim lane boundary, a document should specify what information/data is wanted, the format of the information/data, the schedule for the transfer, etc. In simpler terms, there should be “expectation connectivity” between the sending and receiving functions.

This concept has merit and value in SW design when one program, module, subroutine transfers information/data to another. An interface spec should define this stuff. This approach is generally helpful in those environments that try to create re-usable SW and develop SW libraries for future projects/applications. The swim lane concept has value for any type project but recognize it is but one tool at the project manager’s disposal to bring the project in on time, within budget, and meeting the technical performance requirements.
What a great tool.  I can’t wait to try it. I think it will work just as well in process improvement initiatives.
Thank you so much for all the responses.  I’m really enjoying the conversation, and more importantly – learning a lot!

-Judi