Web Development

General discussion


Project Analysis: Best Practices?

By Underground_In_TN ·
Non-IT people are big on new ideas for programs and/or systems to help them do their job, but typically come with vague notions about the detail. It is up to the programmer/analysts to ferret out exactly what the users need, fill in the details and come up with the specs upon which the project is built. The better the up-front analysis, the less amount of time is wasted going back and rebuilding/redesigning things that don't really fit the need.

What methods and/or tools do you use that help you get the most details and the best vision of what the user needs and wants, and minimize how much you go back and make corrections to the initial specifications?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Successive Approximation

by Wayne M. In reply to Project Analysis: Best Pr ...

I am afraid the rebuild/redesign step is necessary and should be embraced and not viewed as an indication of failure.

Users are often doing fairly complex tasks that they understand quite well. It is time consuming to bring the developers fully up to speed on what all of the users needs might be and to get users to verbalize their basic assumptions. This is why I favor iterative approaches, i.e., get something in front of the users as quickly as possible and expect to update it often. I also believe that working software is a far better media for communicating to the user than any form of written document.

Minimize the time spent on creating paper representations of the system and instead concentrate on creating a tight feedback loop with (selected) users.

Collapse -

Minimum standards

by Prefbid II In reply to Project Analysis: Best Pr ...

This hits at one of my push-buttons. I agree that often a user does not fully understand the process that they are in and needs something more than a piece of paper to describe what they want. This is because:

1. What they actually need may not have been invented yet. We have not come so far that creativity is not required.

2. They may have done it so long the way they are used to doing it, they can't see around their current method to include other posibilities.

3. They may not know what is possible.

4. They may not know how to describe it. They can do it, but they can't teach it.

So, here are some ideas.

1. Find an expert on the old method -- who is an excellent teacher. If you have a training group, grab one of their people. They are usually the ones who know enough about the process to break it down into digestable steps.

2. Use a white board and brainstorm a lot with the users. It usually helps to have the eventual user and programmer in the same room. Don't invite users who are not creative.

3. Build Use-Cases. Even if you are not going to use OO programming, use OO design. I've found that users are very good at stating use cases, even if they are not good at writing them down.

4. Get frequent checks on your mock ups. As you begin to put your solution together, you will discover things that need clarification or even decision points. This is not a problem -- this is a mark that you are on the right track.

Collapse -

They don't know what they want

by Tony Hopkinson In reply to Project Analysis: Best Pr ...

what they have, what they need, what's already available, what the alternatives are or what they could have.
So why should we? We aren't psychic.

Short regular iterations, constant review and avoid designing holes to fall into, corners to be backed in or traps to spring next week.

A list of desires, cost, prioritise, iterate, test, assess. Review and start the process again.

Change is a given so embrace it and make use of it.
Look at the reason why you want something specified.

To cost it properly, because it's the core of the application, to get on with the task, to cover your *** with when everything goes pear shaped.

As soona s youi have a general idea of what's required, come up with an overall structure. Look at the design path. Do what you have to do to get the first achievable deliverable to the customer.
Wahen they se it they'll think of three other things they want, one that they consider less important and two that they forgot. Next iteratation. Give a reasonable level of competence on the developer's part, the customer always gets something they want and soon.

Collapse -

Exactly! You must learn and understand what they do

by The Chad In reply to They don't know what they ...

As the parent stated, the bottom line is that the users do not know what they want and they do not know what possible solutions look like.

Most people in userland never look at the big picture, let alone understand data, so they cannot even begin to craft a solution.

_YOU_ must invesitigate and learn how the project fits in with the rest of the company, understand what the user(s) are really trying to do---what is causing them pain?---and then craft a solution.

In short, you must learn their jobs better than they know them, and then take your knowledge of technology to create a solution.

As Joel (on software) was fond of saying, repeat after me:

- The users do not know what they want.
- The users do not know what they want.
- The users do not know what they want.
- The users do not know what they want.
- The users do not know what they want.

Collapse -


by Tony Hopkinson In reply to Exactly! You must learn a ...

So all attempts to understand everything that users need now never mind next year are doomed to failure.

Build change in to the process, not break the process with change.

There are occasions where waterfall, classic V old style design will work. They are very very rare though. Things like hardware interfaces. If there is human input though, forget the idea, it's now a bean counter/ cya mechanism.

Why didn't you think of that when you designed it.
Why would I, you never told me about it.

Bean counter
Why didn't you think of that when you designed it.
I did, I costed it, you said it was too much.

Why didn't you think of that when you designed it.
I did, I told you it would take six mionths, you said you'd already sold it.

Don't cover your ***, cover your bets.

You've as much chance of knowing their entire environment as they have of knowing yours, or theirs come to think of it.

My favourite.
What's this ?
Order Number
So it's a number
Of course
It won't let me put the order number in


That's not a number.

Yes it is !

But it's got letters in it

Not always ...

Doomed I say, we're all doomed.

Collapse -

That was an awesome example

by Justin James Contributor In reply to Indeed

The bit about the order number, so familiar to me...

One of the ways I sometimes need to deal with customers is to pretend that I am a child and and they are my parent, it is the only way to get actual understanding from them:

Them: Now we enter an order number.
Me: What's an order number?
Them: It's a number that is unique to the order.
Me: Is it always a number?
Them: It is a five digit number with three letters at the end.
Me: Where do order numbers come from?
Them: They are based on the date for the first part, and the letter increments with each order.
Me: Why do bad things happen to good people? Where do babies come from? Why can't we all just live in harmony? I need to go potty!

And so on. If you have a customer who understands the "Mommy/Child Game" and know that you are trying to help them, not annoy them, the results are incredible. I've found that rigorously interrogating the customer and taking good notes makes writing the code a snap, they've written the pseudo code already, you just need to translate it to the language of your choice...


Collapse -

User's needs

by LibraryGeek In reply to Exactly! You must learn a ...

As both parents state "users do not know what they want."
Actually, I would adjust that to "users do not know what will meet their needs." Unfortunately, they often have entrenched "wants" that may not meet their needs.
As a librarian, I was trained to conduct reference interviews. In library-land, patrons and clients often do not know what they need. (see the similarity?) The trick is to get them off of the topic of what they think the answer should be and on to the topic of what are they trying to accomplish? This is quite similar to the blog post and discussion that discusses anticipating users' needs. People go to a librarian and request a particular book or with a preconcieved idea that they ought to find a particular book in the business area -- but their answer is better addressed by information & articles in a particular economics database.

It is only through careful elicitation of what they are trying to accomplish, what problems they need to solve, how do they currently accomplish these tasks that you can begin to formulate an answer. I am doing a lot of user interface work and I find that watching people carry out their tasks helps me understand what their typical work habits. I am a strong advocate for software that stays out of the users' way. That is, it is a tool that can be incorporated into their current tasks with a minumum of training. People hate change and some will resist and rebell to an unbelievable extent! If they don't use the application, then it's failed to meet the need.

It is eye opening to watch someone use your interface -- they often take approaches you would never have imagined. Sometimes it's an individual quirk and you don't want to program to satisfy every individual. However, sometimes you find a substantial group taking an approach that did not occur to you -- that is the time to adjust that application! This is probably the type of incident that prompts some techies to state that you "should't try to anticipate the needs of the user."

Collapse -

What's the Question?

by david.daniels In reply to Project Analysis: Best Pr ...

Believe it or not, the Project Management Life Cycle (PMLC), in my own humble opinion is the easiest way to kick off a complex project; however, three questions/issues come to mind:

1) Does the integrator (engineer) know what questions to ask, in order provide a solution that may or may not exist? If you go back for redesign too often, the end-user may start to question your abilty to solve their problem.
2) Does the customer (end-user) know what questions to ask? Just because a problem must be resolved gives no indication that the end user knows what to ask for. They need help defining the problem first. Refer to PMI: (PMLC)A document called the PMBOK.pdf has more information on this than you'll ever need. (Project Management Body of Knowledge)
3) Most importantly, what they what and what they ask for are usually two different things. Define the problem.

With government; usually Federal, you are restricted to "how" you ask questions, which are usually published to all of the other competitors. It's difficult to stick-your-neck-out and appear inexperienced. Define the problem during the site survey/problem interview, if given the opportunity.

Commercially, the project is more relationship-based; therefore, the crux becomes how well the relationship is formed with the customer. Commercially, when a project is awarded, they know before the RFP is put out; therefore, with the relationship as the bond, those customers already know what questions you will be asking.

Sorry to ramble, but I have OFTEN struggled with this issue and the bottom line for me is this: Finding a "fit" to accomplish the task at hand; and that is ALWAYS a crap-shoot . . .



Related Discussions

Related Forums