Writing good specifications

I was tasked to help helpdesk on workstation deployment because current environment requrie a lot of dissimilar hardware model, and many applications sets for different group users. Currently, many people has been involved in creating disk cloning image for fast PC deployment and thus has create a mess of version and mess of non-working problem. I 've heard that this netbios service need to be disable and immediately the other person said it is required for SAMBA. I don't know why they are so keen on reduce the windows XP components and disable a service. However, the communication and cooridiation has failed apparently. Now that what is my role to play when come down to this mess and detail-oriented work?

I am thinking about two things and get them half-complete this morning.

First , a high level definition of this topic, which provide a full picture that I badly need
Second, Roles and Responsibility , which define the roles and res among help desk, system admin, IT manager, and security admin.

Now, I come aross this book " Art of project Management" which talk about good specification and the writer have obviously argue for it and deal with the disagreement. Here come the story......

I once had an argument with a programmer who believed that we didn't need to write specs. I walked into his office with this big template I'd been told to use by our boss, and he just laughed at it (and unfortunately, at me as well). His opinion was that if what I wanted to do was so complicated that I needed 50 pages to explain it to the programmers, it wasn't worth building anyway. He saw the need for all of this process and paperwork as a signal that communication and coordination on the team were failing, and that we weren't trusted to decide things for ourselves. We shouldn't need so much overhead and bureaucracy, he said, implying that elaborate planning was never necessary.
Having had this argument before, I smiled. I asked him if he'd make the same claim about the engineering plans for the hi-rise apartment building he lived in or the three-story highway overpass he drove on to get to work. But apparently he had heard this question before, and he smiled right back. He said that while he was glad those things were planned in great detail, he didn't think working with software was quite the same as working with the laws of physics and construction materials. We quickly agreed on two points. First, that compared to traditional engineering, software is more flexible, easier to change, and rarely has people's lives at stake. But, we acknowledged that because we faced complex engineering challenges, had a team of people depending on our decisions, and had budgets and deadlines to meet, we needed more than our memories of hallway conversations to make sure the right things happened.
We also agreed that what we needed for our project was something suited to the kind of work we were doing and the kind of people we were. Some sort of written documentation would be useful if it solved real problems for our team, accelerated the process of getting things done, and improved the probability of a quality outcome (and it needed to be updatable over time without upsetting anyone). If we could make something that achieved those things, he said he would gladly use it, regardless of what we called it or what form it came in. And with that, we revised the spec process down into something we agreed would work for our small team. I went back to my boss, rehashed our conversation, and worked out a compromise. The big, tax law-size spec template went away.
The key lesson from this story is that like anything else people make, there is no one right way to write specifications or to document work. Specifications, like most things teams are asked to do, should match the needs of the current project and the people who will have to create and read them. And in the same way that web sites or software products need to go through a design process to find the best approaches, specifications need some thought and iteration to be done correctly.
But many experienced people I know have fallen into the trap of believing there is only one way to do specifications (or whatever they call them), which tends to be whatever way they did it last time. Sometimes this chain of repetition goes all the way back to the first projects they worked on. They assume that because those projects weren't complete disasters, the way they wrote specs contributed positively toward that outcome: a claim that without any investigation may or may not be true (i.e., the project might have succeeded in spite of a dysfunctional spec process). Worse, if good questions about how and why specs are written have never been asked, no one on the team really understands how good or bad the spec writing process really is, or how much it does or does not contribute to the team's performance. (This is entirely similar to how the absence of good questions about writing quality code prevents the possibility of understanding how good or bad the code really is.)
My aim in this chapter is to explain the following set of ideas. First, that specifications should do three things for a project: ensure that the right thing gets built, provide a schedule milestone that concludes a planning phase of a project, and enable deep review and feedback from different individuals on the course the project will take. These three things are very important, and it's unlikely that a process other than written specifications provide them all at the same time. For that reason alone, I'm a fan of specs. Second, most of the complaints people have about specs are easily remedied, provided their authors understand the common pitfalls of spec writing and recognize the specific benefits specs should be used to provide.