January 26, 2008 at 11:49 pm
Comments posted to this topic are about the item Tell Me What You Need
January 28, 2008 at 6:19 am
How many of you have actually asked for requirements for a project, been given some, and then all of a sudden new requirements come up while you're in the middle of coding?
This never happens to me Steve - I don't know what you're talking about. Does this happen to other folks?
Great editorial (again)! This is a great reason for developers and database professionals (i.e. me) to work on our soft skills. Communication with the 1s and 0s is essential to being a good coder. Communication with people - especially expectations - is becoming more and more important.
:{> Andy
Andy Leonard, Chief Data Engineer, Enterprise Data & Analytics
January 28, 2008 at 6:29 am
I worked for one company where a client signed a contract for the product with a specified set of features. A Functional Specification was then written specifying the features and gets signed off by the analyst that wrote the spec and the client. During the development and coding phase, requests for new features would come in from the client. The analyst would create problem reports against the program as a way to add the new feature to the list of requirements. I asked her why doesn’t she revise the Functional Specification? She said, “Because it is a signed contract.” Needless to say, the project never got completed because of the continual changing requirements and adding of features. Once, I wrote a problem report against the functional spec. She took it personally and it caused all sorts of grief in the company.
It seems that the way the company did business involved getting a contract and then asking the customer “Do you want to supersize it? It’s free.”
January 28, 2008 at 6:31 am
How many of you have actually asked for requirements for a project, been given some, and then all of a sudden new requirements come up while you're in the middle of coding?
I think this happened one too many times here, because now we have a documentation process that's being put into place and now our clients are getting locked into functional specs and a hellish alteration process.
January 28, 2008 at 7:26 am
Project Plan? You mean there's a PLAN? hehe....
It's a definite challenge. You have to have a vision of where you're heading, but let's face it - there's no real guarantee that you will "like" where you end up, which is why there seems to be so many new things thrown in half way through. Our failing in all this is to not push back hard enough when one of those "twists" just upends the applecart, wrecks the timeline; more ofthen than not we put up a feeble protest, then try to kill ourselves along the way to trying to meet this now fully unrealistic deadline.
Just about the only thing I've found that helps at all it seems is to beef up on prototyping. Give the user something to look at, that will look like all or part of the end-result. Whiteboarding is cute, but unless the user has enough in front of them (yes - them at the keyboard), then they don't have enough to get their mindset on to be fully effective... And this is STILL no guarantee....
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
January 28, 2008 at 8:29 am
It's definitely a balancing act when "new specifications" (i.e. changes) come in. We're just starting to use "Use Case" documents that the user needs to sign, but we're not using them to lock down the requirements - instead they're a tool so that 1) the users and IT have a document to refer to so everyone knows what was asked for/promised, and 2) we all have a grasp of the minimum overall functionality that needs to exist.
Yes, we've had lots of refinements and a few totally new functions thrown at us. Some have been incorporated into Phase 1 (due to significant need or benefit), and some have been put into the Phase 2 category. The use cases have helped justify the Phase 2 issues, and our users are now to the point where their requests are phrased in term like "It's not in the use case, so this will be a Phase 2 item". Hallelujah!
No one (and no team) can or will think of everything during the design phase. Change is inevitable in any project; I don't think we can or would want to stop it. The trick is to manage it in such a way that the critical needs of the business are met, and the project meets it's deadline (even if the deadline has to move because of the scope of changes). I think most users are frustrated by the same things that frustrate us - products that don't work as advertised, and products that are delayed again and again and again for no good reason that they can see (think Microsoft new product releases; it's the standard "joke" gripe in this forum!) Communication is critical, but it also needs to be the correct type of communication - the users need both to understand it, and to buy into the underlying concepts.
In some ways IT has created its own problems. As programmers we are "locked away" (in ivory towers or dungeons - to keep us geeks away from the "normal" people) and to many people what we do seems like magic just because they don't know how to do it. The "worship us" attitude has been encouraged in some companies, and it adds to the problem. There's nothing worse that setting yourself up as a little god and then under-performing. It's a good way to get burned at the stake! Now times are changing and we need those soft skills that we were discouraged (or actively prevented) from getting years ago. So go out and get them, and then start educating your users on what you need from them for a successful project. It will take time, but it WILL be time well spent!
Steph Brown
January 28, 2008 at 8:43 am
Because of this problem we're instituting strict project management controls. Everything will be spec'd out, and if a request for change comes in after everyone signs off and development begins, it'll probably be pushed back for a subsequent project and have to go to the back of the queue.
Oddly enough, I've never been burned by moving target reqs. Most of my projects are only one or two developers, and our initial specifications were sufficiently complete that a realistic change coming through wasn't difficult to accommodate. That's definitely going to change, so we'll see how project management works out, especially since I'm not the project manager!
:hehe:
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
January 28, 2008 at 2:08 pm
I had worked for companies with all sizes. The small size companies usually did not have project plan, my manager gave me users' request, some just said 'Need Finance Report ASAP'. I had to go and talked to the user and asked them what they wanted.
For medium and large size companies, there were always project plans. As a matter of fact, there were project definition, project plans of each function of the whole project. functional spec and technical spec. Unfortunately IT usually was not involved in creating the project plan, the project managers or the business analysts created them. They gave it to me and I wrote the functional and technical spec. In some cases, I had to tell the project managers or business analysts that it could not be done because we did not have the data or it would take much longer time and could not meet the deadline. One time the project was creating a few reports. I wrote the functional and technical specs for those reports and had the users to review them. I wrote the specs based on the project plan from the project manager. The users looked at it for one minute and said those were not the reports they wanted. It was totally wasting time.
The developers should be involved in creating the project plans because they are the one who know what kind of data in the system, how long will it take to change the system or create a new system. Unfortunately most big companies never involve the developers in talking to the users. The project got delayed, things were misunderstood.
Whose fault was that? Not me!!!!!!!! My program always worked according to the project plans!!!!!!!!!!!!!!!!:w00t:
January 29, 2008 at 3:42 pm
When I was doing independent consulting and developing, I got burned by this sort of thing . . . the proverbial "perpetual scope creep". I then revised my contract so that it consisted of a 2 page, base contract that basically said, "we're going to do business. I'll do what you tell me to in the addenda, I will bill you on a periodic basis, and you will pay me when billed." and, when we agreed to do business, we both signed it. (Of course, there were some "boilerplate" paragraphs to protect both parties. 😉 I would meet with the potential clients, figure out if I could help them, prepare a summary of their stated desires as Addendum A to the base contract , and, when Addendum A looked like what they wanted, we would sign it. If the client decided that there needed to be a change to the product, then I wrote up an Addendum B and we went through the same process.
Now, there were the occasional situations where a client realized that Addendum A was absolutely no longer what they wanted (in fact, there were even occasions where the entirety of Addendum A was discarded). That was provided for by a "Date Completed or Canceled" and another set of signatures. There were also occasions when the client would decide that a portion of the work covered in Addendum A needed to be replaced by a different choice, which was covered in Addendum B, and I had no problem with that . . . especially because I would simply draw up an Addendum C that incorporated the new overall statement of work and then we would cancel both Addenda A and B. (The new statement of work would specify the state of the work to date, the reason for the revision, and those portions that were being revised.) Of course, every Addendum carried a start date (date signed), an expected duration, and an expected due date. I also provided status reports on the progress associated with each of the addenda.
As a side note, I only had one client that objected to the over all process . . . a lawyer. I started to bend my rules to accommodate that client and then I learned from a fellow independent developer that the lawyer had pulled the "perpetual scope creep" on him and refused to pay until the project was "totally completed" . . . which never happened because of constant revisions.
I think that far too often the reason for the changes and scope creep that tend to go along with poor requirement specifications is not so much laziness as it is what I refer to as the Hollywood Syndrome that too many people have. The Hollywood Syndrome surfaces when someone has seen too many instances of a TV or movie character breaking into a foreign (either in the sense of unknown or in the sense of other national) office, sitting down at a terminal, somehow "knowing" the password (or hacking it), typing about 20 to 25 key strokes, and magically getting a beautifully formatted report of exactly the information they are looking for . . . on the first try! People who suffer from the Hollywood Syndrome have no concept either of what is involved in what they are requesting or of what the impact is of the changes that they are demanding. Everything takes only 20 to 25 key strokes in their mind, so they figure that changing something can only take, what, 5 key strokes? :crying:
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply