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

My Cure for Overambitious Projects

You’ve probably encountered clients that request an unrealistic amount of features to be included in a product. They’ll start by listing a few features that the product “absolutely must have,” which suddenly reminds them of a few more features, which then brings up more that “we probably should include.”

Meanwhile, your headache is growing because you know that such lofty expectations always fail.

Well, it’s time like this, before any of the development begins, that you’d benefit from splitting up feature requirements into two categories: essential and supplementary.

This simple action will save you enormous stress later on in the development process, because it forces both you and the client to agree on what is most important, and what can wait.

After you make the list, give a copy to your client, and keep one for yourself. Whenever an issue about including more features comes up, refer to the list and ask, “Is this truly necessary?”

-Judi

Some More Comments on Overambitious Projects

I previously asked readers to share their experiences with overambitious projects. Here were some of the replies:

Creative people always desire to create a perfect product. And it is very difficult to stop perfecting it… It’s not easy to differentiate between essential and supplementary features.

Also interesting fact from the “big science” molecular biology – the Human Genome project (that was also saturated with computation and programming). Finishing sequencing took as much time as the first 90% of sequencing work.

So true. There's an understandable amount of pride that creatives and entrepreneurs feel about their work--sometimes to their detriment.

And also this suggestion on how to handle feature-hungry clients

As a product manager, I have dealt with this issue many times.  It always helps to ask the client (internal or external) to estimate the additional sales that will occur if the new feature is added.  Invariably they either realize the answer is zero, or understand they have no way to credibly answer. No additional sales, no money for development. Simple but effective.

What a fantastic idea. It lets the client clearly see the value of each additional requirement.

-Judi