The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

1. Failure to Apply Essential Project Management Practices. Many
troubled projects fail to apply proven project management disciplines
like cost estimation, project scheduling, resource planning,
configuration management, and proactive risk management, then wonder
why their project is in constant turmoil.
2. Unwarranted Optimism and Unrealistic Management Expectations.
Some managers recognize the potential for negative impact on their
project from potential problem areas; however, they choose to see
things through rose-colored glasses, assuming that problems will work
themselves out even when all available evidence raises the red flag.
3. Failure to Implement Effective Software Processes. Many
projects fail to implement effective software processes because their
approach to process application is not balanced. Some apply minimal
process and rely on staff expertise, while others insist on rigorous
global process conformance.
4. Premature Victory Declarations. Pressures to deliver timely
products often result in premature declarations of completion by
managers. Success cannot be declared until products have been
completed with the built-in contracted quality and reliability.
5. Lack of Program Management Leadership. Managing a software
project requires "courageous" and often clairvoyant individuals who
are willing to confront today's challenges to avoid tomorrow's
catastrophes. We have observed two types of problem managers: those
with software engineering and no management experience, and those
with management and no software engineering experience. Both types
lack the ideal blend of both technical and managerial know-how.
6. Untimely Decision-Making. Some managers avoid making time-
critical decisions until it is too late, even when they are faced
with overwhelming warning signs of impending problems.
7. Lack of Proactive Risk Management. Many projects claim to
implement risk management but few do so effectively. "What
distinguishes the best organizations and best managers is not just
how well they do in their successful efforts, but how well they
contain their failures [5]."

Tell us about your Dysfunctional Software Project....

If you can't be a good example, then you will serve as a bad warning.

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

Effective Communication Skills "for scientific and technical
professionals" by Harry E. Chambers, copyright 2001.

There is another book which is an older book but also has good
insights: People Skills, "How to Assert Yourself, Listen to Others, and
Resolve Conflicts" by Robert Bolton, PH.D,, 1979

What makes a good Software Tester?

1. Know Technology. Might as well start out with the most
controversial one. There's a popular myth that testing can be staffed
with people who have little or no programming knowledge. It doesn't
work, even though it is an unfortunately common approach. There are
two main reasons why it doesn't work.

(a) They're testing software. Without knowing software develop,ent, they can't
have any real insights into the kinds of bugs that come into software and the
likeliest place to find them. There's never enough time to test "completely", so
all software testing is a compromise between available resources and
thoroughness. The tester must optimize scarce resources and that means focusing
on where the bugs are likely to be. If you don't know programming, you're
unlikely to have useful intuition about where to look.

(b) All but the simplest (and therefore, ineffectual) testing methods
are tool- and technology-intensive. The tools, both as testing
products and as mental disciplines, all presume programming
knowledge. Without programmer training, most test techniques (and the
tools based on those techniques) are unavailable. The tester who
doesn't know programming will always be restricted to the use of ad-
hoc techniques and the most simplistic tools.

NOTE: Taking entry-level programmers and putting them into a test
organization is not a good idea because: a programmer that does not have a
passion for detail will not have the eye for detail necessary for an entry level
tester.  Putting new hires in the testing group is not the way to give them on
the job training, it's a recipe for poorly tested software releases.

2. Credibility With Programmers.
Independent testers often have to deal with programmers far more
senior than themselves. Unless they've been through a coop program as
an undergraduate, all their programming experience is with academic
toys: the novice often has no real idea of what programming in a
professional, cooperative, programming environment is all about. As
such, they have no credibility with their programming counterpart who
can sluff off their concerns with "Look, kid. You just don't
understand how programming is done here, or anywhere else, for that
matter." It is setting up the novice tester for failure.

Got an opposition opinion, a comment or observation?  Feel Free to share and/or
vent to the group!


3. Know the Business Application.
That's the other side of the knowledge coin. The ideal tester has
deep insights into how the users will exploit the program's features
and the kinds of cockpit errors that users are likely to make. In
some cases, it is virtually impossible, or at least impractical, for
a tester to know both the application and programming. For example,
to test an income tax package properly, you must know tax laws and
accounting practices. Testing a blood analyzer requires knowledge of
blood chemistry; testing an aircraft's flight control system requires
control theory and systems engineering, and being a pilot doesn't
hurt; testing a geological application demands geology. If the
application has a depth of knowledge in it, then it is easier to
train the application specialist into programming than to train the
programmer into the application. Here again, paralleling the
programmer's qualification, I'd like to see a university degree in
the relevant discipline followed by a few years of working practice
before coming into the test group.

Are you a software tester?  Are you thinking about a job or position in software
testing?  Here are the top 12 qualities identified for software testers. 
Prepare for your next interview or identify why you should get a raise by using
these key terms:

1.  Methodical
2.  Analytical
3.  Tactful
4.  Diplomatic
5.  Skeptical
6.  Detail Oriented
7.  Experiments
8.  Gets Hand Dirty
9.  Go Communicator
10. Anticipates
11. Able to See Multiple Points of View
12. Tenacious


Learn more about the career field of software testing, look for the book named
"So You Want to Be A Software Tester" @ Amazon.com

Be in the know - Impress your friends, your boss, your colleagues.
Use these words on your next interview. Sound smarter in meetings. Get
a $$$ raise or promotion. It's amazing what knowing the right
buzzwords can do. This are the words you need to know for 2008:

1. COE, CORE - Center of (Requirements) Excellence
2. Agile
3. Delayering, Churn rate
4. Deep Dive
5. Bleeding Edge
6. Mindshare, Clickthrough
7. Eyeballs
8. Paradigm Shift
9. Customer Life Cycle, Customer Acquisition Cost
10. Six Sigma / CMMI / Process Improvement

Do you know of a 'hot' new IT Tech buzzword that's not on the list?
Send it to us today.

Wachovia started their BA Center of Excellence 18 months ago.  They
had unpredictable project cycles, no concise way to measure ROI,
customer satisfaction after project closeout was poor and they had
waste with their SDLC.  There was also confusion around what are
requirements, why are they valuable and what makes a good requirement.

It was mentioned that you have to work incrementally by starting out
with a Community of Practice (COP), progressing to a BA Bureau and
then to a Center of Excellence (COE).  One way to think of the
progression is as a bulls-eye with the Community of Practice as the
outer ring and the Center of Excellence as the bulls-eye.

Where do you start?  The model is designed like a
checklist - start with the first row for each column and work your
way down the model to move from a Community of Practice to a Center
of Excellence.

Why build a Center of Excellence?  The benefits include:

decreased risk on our projects
increased value for our projects
improved quality of our deliverables
improved time to deliver our goods and services

The Five Factors for Success:

1. Have a plan (from concept to enterprise analysis)
2. Create a framework
3. Obtain executive sponsor
4. Align corporate goals (what's the value perception?)
5. Define roles and responsibilities (who's going to maintain it?)

"Having a plan" - was the most critical step.

What's the next step, contact us for more training and coaching.

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

1. Have key roles (i.e Project Managers and Business Analyst) assigned
to do dual rolels
2. Putting the "how" requirements before the "what"
3. Not asking the user the "how" question at all
3. Building a system based on random "system shall" statements
4. Leting the Project Manager tell the Business Analyst how to gather
requirements and how much time they need to accomplish it
5. Asking the right questions but asking the wrong people
6. Ignoring best practices and lessons learned related to requirements
7. Not having a requirements plan
8. Avoiding conflict and not identifying contradictions related to
requirements
9 Reviewing the requirements too little too late
10. Having a Business Analyst that is not a good "agent of change and
consensus"

Want to know more about the "10 Stupid Things Done On Projects", email
us for a complete white paper on the subject.

In 2008 you can look forward to our online internet virtual panels. You
can Log In, Call In or Email your questions and get them answered
realtime. We will be having monthly virtual panels of seasoned industry
practitioners who can provide you input and ideas on topics related a
project your working on or on helping you define your career path in
Software Development ... It is a unique and convenient opportunity to
share and learn....

Look for future announcements about dates and times for our monthly
virtual panels....

Interested in being on one of our virtual panels?  Email Us.
Got a Topic for a panel discussion?  Email Us.
Know of any good books worth discussing?  Email Us.

jkay@...

Start a CORE ....what's a Center for Requirements Excellence (CORE)?  Its the
equivalent of a PMO for Business Analyst and Requirements Gathering.  And anyone
thats work on an IT project that has failed or is struggling knows that the root
cause is poor requirements.  Want more info,  email moreinfo@...

The following file was arranged to be sent to the ITProFrustratedNoMore
group automatically.

   File        : IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only
   Size        : 3231 KB

However, due to the large size of the file, it is not sent
through email.  Instead, you can access the file at this URL

http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the ITProFrustratedNoMore
group.

   File        : /IPI_12_Step_Process_Improvement_2007 Sept 28 Free.doc
   Uploaded by : djj20012001 <djj20012001@...>
   Description : 12 Steps To Process Improvement (Free Quick Reference) Available
Here Only

You can access this file at the URL:
http://groups.yahoo.com/group/ITProFrustratedNoMore/files/IPI_12_Step_Process_Im\
provement_2007%20Sept%2028%20Free.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/us/groups/files

Regards,

djj20012001 <djj20012001@...>

If you were a project manager building a house, would you do any of
the following:

Would you build a house without a blueprint?
Would you let a customer add a room, a wall, move a door, or
eliminate a window during construction – without changing the project
schedule and charging the client the additional cost?
Would you start building a house, without a signed contract stating
all of the requirements and the cost?
Would you bypass home inspections and reviews that are industry
standards?
If your expertise and experience is building two story wood frame
houses, would you take on a job to build a highrise out of wood
because the customer ask for it?
Would you or could you ignore the cost of the project, the profit
margin or the impact of rework and overtime?
What would be the cost, if you built a house in iterations?  Build
one room in the first interation and then another room in another
iteration – creating the foundation and infrastructure for each in
separate interations.  Wouldn't the integrity of the foundation be
compromised?
Can you take a building that was built with one intent and use it for
another purpose and not expect some compromises?  i.e. A dwelling
that was originally a home that is convert to also be used as a home
business (i.e.  a daycare will require certain adjustments but will
never perform as well as a  building built with the express purpose
of  being a day care)
Could you change the scope or objectives of a project significantly
and not change the project? i.e.  Would you let a customer change the
scope of a project from a church to a school?
Would you embark upon a project that will cost $500,000 and not have
any project documentation?

Why should IT be the exception?


For more information visit www.Success Architechs.com or write
moreinfo@...

'I don't mind coming to work,

But that eight hour wait to go home is a challenge.'

We are in Search of the perfect, comprehensive and a user friendly
traceability matrix.  Tell us what you think should be include in a
traceability matrix (i.e. Req. ID, Requirement Type, Requirement
Description, Trace from Requestor/User, Trace to System Feature, Trace
to Design Spec, Trace to Test Script).

Let us know if your organization uses traceability matrices, how they
use them, what they implement and insure they are maintained and up to
date.

Recieve a free download of our Process Improvement 12 step guide for
submitting any suggestion we publish to this discussion group.

Thanks!

Which BOK do you adhere to?

Canadian Information Technology Body of Knowledge (CITBOK) is the
project sponsored and undertaken by Canadian Information Processing
Society (CIPS) to define and outline the Body of Knowledge that
defines a Canadian Information Technology Professional.

CIPS recognizes that in order to strengthen the criteria of the
I.S.P. designation successfully while still maintaining high
standards, the association needs to develop a Canadian Information
Technology Body of Knowledge (CITBOK) that will set standards for
knowledge. The CITBOK is an outline of the knowledge bases that form
the intellectual basis for the IT profession. CIPS has identified a
core CITBOK that all professionals would be expected to master and
specialty bodies of knowledge that would depend on your area of
practice. When setting this Canadian standard for Information
Technology (IT) knowledge, CIPS looked to other organizations and
internationally for standards and bodies of knowledge that CIPS could
adopt or adapt, especially for the specialty areas. For example, in
2004, CIPS adopted the British Computer Society (BCS) Professional
Examination Study Guide Syllabus Diploma level (Core and 11
specialist modules) as the initial Body of Knowledge for CIPS.[1]

The CITBOK aims to:

be an industry structure model that can be used to define the set of
performance, training and development standards for all IT
practitioners (CIPS members and non-members) in Canada;
create alternate paths to certification based on concepts of CITBOK;
establish guidelines for accreditation criteria based on concepts of
CITBOK; and
create a professional development model that sets the standards
criteria for the knowledge base including knowledge, skills, and
professional activities for IT practitioners.

---------------------------------------------

The Software Engineering Body of Knowledge (SWEBOK) is a product of
the Software Engineering Coordinating Committee. The IEEE Computer
Society is also involved.

The software engineering body of knowledge is an all-inclusive term
that describes the sum of knowledge within the profession of software
engineering. Since it is usually not possible to put the full body of
knowledge of even an emerging discipline, such as software
engineering, into a single document, there is a need for a Guide to
the Software Engineering Body of Knowledge. This Guide will seek to
identify and describe that subset of the body of knowledge that is
generally accepted, even though software engineers must be
knowledgeable not only in software engineering, but also, of course,
in other related disciplines. [1]

DESIGNING DEVELOPER FRIENDLY IT PROJECTS
by Jacqueline Sanders
(c) 2007

Software Developers works in very hostile environments.  Not in the
physical sense but in environments where they are set up to fail or
to feel defeated.  They work on projects that require heroic efforts
which translates into long, stressful days and massive overtime -
only to be blamed for missed deadlines, poor quality work and
disgruntled customers.  They in turn have to defend themselves by
blaming the project manager for setting unrealistic schedules, the
stakeholders for changing the scope without changing the deadlines,
the business analyst for providing incomplete requirements and the
testers for not finding the bugs in time for the final deadline.
Unfortunately, Information Technology (IT) resources jump from one
job to another just to find the same work environments no matter
where they go, and no matter what methodology de jour, is being
applied.  It's no wonder seasoned software developers get burnout and
are looking for a way out of such an unrewarding career path.
If one single factor could significantly improve IT project teams and
create `developer friendly IT projects', the last thing that would
come to mind is the Technical Design Document (TDD).  Developers are
relatively adverse to reading and writing documentation.  And in more
recently years, the TDD seems to becoming more and more extinct.
Anit-Documentation Software Developers (ADSD) loathe requirements
specifications, they despise design documentation. And meetings to
review them is the baan of their existence.  Documentation is
considered a nuisance, a roadblock, a bureaucratic evil.  ADSD's will
proclaim that most of what is in a Business Analyst Requirement
Package is over kill, fluff and of no use.  At best, Requirements
Packages are suppose to keep the stakeholders from changing their
mind in latter phase of the software life cycle but history has
proven the scope is rarely enforced.  In reality all too often, ad
hoc or spontaneous requirements have precedence over whatever is in
the documentation.
For Developers the all too painful lessons learned is that with each
new project you are expected to get more done in less time. With
today's high level languages, development methodologies, tools and
the "rapid application development" mindset, both developers and
managers have become accustomed to extremely fast development cycles.
Developers are now more inclined to jump directly into development,
fearing that every hour they are not writing code will result in an
hour of overtime the weekend before the deadline.
The process of designing, even informally, on a whiteboard before
coding is becoming atypical. Documenting designs in written format is
becoming unheard of. "Many developers have never written a design
document and cringe at the idea of doing so."  The crux is creating a
Practical Design Document that mitigate the typical project hazards
in the IT environment.
The only way to convince Anti-Documentation Software Developers
(ADSD) of the value of a pragmatic Design Documents and it's
prerequisite Requirements Specifications is to illustrate how a
design document directly defuses the hostile conditions under which
developers are currently subjected to in the workplace.
Technical Designing For A Better Work Environment
A design document is a way for the development team to communicate to
others what their design decisions are and why their decisions are
good and/or necessary decisions. Traditionally the design document
was written for your development team, so that as you divide the work
you all would have a single blueprint.
This presents a problem, however.  The design document needs to have
a much broader audience.  After the development designer
subconsciously filters and interprets the requirements and functional
requirements, there is often a missing feedback loop.  The
stakeholders and specifically the Business Analyst, Project Managers,
and Tester  need an opportunity to review the design of the
solution.  Furthermore, the design solution should not be just one
solution; it should be a range of solutions. Preposterous? No.
When you get the requirements to design a new home, would you create
the blueprint and then not review and sign off on it with the buyer,
the general contractor, and the county inspectors before you start
dividing up the work and start to build it?
The template we give you makes it as simple as answering a
questionnaire.
A Technical Design Document can be concise and yet be comprehensive
as a communication tool between the development team and the project
team.  It should take no more than a week.  It's audience should be
the entire project team.  It should require sign-off. And one of the
most critical pieces of the Practical Technical Design Document is
the Development Success Factors (DSF) template which will include the
priority, impact, risk and cost of each of the DSF.
How can you justify not having a Technical Design Document? It both
serves and protects the developers.  It is the contract and voice of
the developer.  What other artifact in the project life cycle is from
the developers view point.  Grumbling about it around the coffee
machine or venting at the post moratorium is too little or too late.
Each of the DSF correlates to each of the factors that make the
Development environment of today the hostile environment we have
grown to known in IT shops across the world. DSF's are intended to
give those developers in the trenches a voice and a template for
better working environments.
1. Reinventing the Wheel and Rework

The majority of software development projects are actually
enhancements or add-ons to existing system.  Sometime you might
happen upon a total rewrite or re-engineering of an existing system.
What developer at some point hasn't looked at the existing system and
said "What were they thinking when they wrote this code?"

Had the previous developers left behind a design document we might
have some insight into what there approach was to creating the
previous or legacy system.  Embedded in such a document would also be
some valuable lessons learned.

Design Success Factor - 1:  Identifying the `As Is' architecture, its
design approach, it's limiting, its constraints.  Not having a design
document of the current architect and system is it's an inherit
risk.
2. Unrealistic Deadlines
The deadlines are real, so your Design Document needs to be realistic
in an informative way.  It's a way to say "you don't know what you're
missing" and later "I told you so (on page 117 of the Design
Document)"

Design Success Factor - 2:  Identifying a range of  `To Be' solution,
ones with the known constraints (such as budget, deadline, resources,
existing architecture) and various of the solutions if one or more
the constraints were alleviated.

3. Crap versus Craftsmanship.

Being forced to build crap is one of the worst things you can do to a
craftsman and is the definition of failure to someone who takes pride
in what they build.  If you buying a cheap product notice it doesn't
come with a warranty or it only comes with a limited warranty.  If
you buy something of quality the craftsman is willing to guarantee it
for a given number of yeas.

Design Success Factor - 3:  Identify, quantify and put a value to
good craftsmanship. (Hint: If you are having troubling finding ways
to measure your craft, turn to the Business Analyst, the tester
and/or the Project Manager on your project team. Also read Six
Sigma.)

4. The right way versus the quick way.

Your design document is your way to set expectations as to whether
they want things done the right way and not just the quick way.
There has been an assumption that there is only one How.  The design
document actually should be multiple choice.  There should be a
review and conversation about picking the right approach – do you
want it the right way or the quick way?  Has the budget, resources
and time been allocated for the right way or the quick way?
Is `quality' an important feature and are you willing to pay the
price.  If the answer is NO, then your design document is your de
facto product disclaimer.

Design Success Factor - 4:  Pro-actively identify the implications of
quick fixes and short cuts. Identify the cost and impact in terms of
rework, maintenance and future enhancements.


5. Not Having the Right Tools

A Design document should define what the developers need in order to
provide the solution and outcome expected.  You can't give a plumber
a toothbrush and a tooth pick and expect them to fix your toilet.


Design Success Factor - 5:  State it in your design document, what
you need in order to give the stakeholders what they want.  You may
need more RAM, more hard disk space, faster/dual CPUs, up-to-date
technology and necessary tools.


6. Scope and Expectations

Project Manager set the scope and expectation for the project.  The
Business Analyst set their scope and expectation of the business and
users.  The Tester have their test plans.

Design Success Factor - 6:  The design document should include the
scope and expectations for the solution and end product. It should
borrow some of the key elements found in the forementioned artifacts,
except they should be documented from the developers point of view,
they include risk, assumptions, constraints, outstanding questions,
change control, approval, revision log, sign off.

7. Motivational Management
An excellent resource and project manager is one that motivates the
team and promotes a cohesive and unified vision.  A sure fire way to
demotivate and kill morale developers is by micro-managing their
work, stifling independent thinking, by making decisions without a
real understanding what it takes to build quality software, having
bureaucratic process, layers of management creating slow decision
making, and a willingness to take a bullet for the team as opposed to
someone who takes credit for the success of the project.

These are the traits of an amazing software manager; the traits of a
manager whose team would bathe in boiling oil to defend her, and work
all-nighters to prove her right. When a manager takes bullets for the
team, good developers tend to return the favor and then some. It
creates an almost cult-ish loyalty, and the results are not only
motivated developers, but insanely good software.

Design Success Factor - 7:  State it in your design document your
management expectations. Depending on previous interaction you may
have to be somewhat subtle.

8. Learning New Things
Developers are happiest when we're learning new skills , exercising
creativity, challenging their existing skills, or solving problems
that matter. This research suggests that we are willing to be paid
less for work that's interesting, fun, and expands our skills.
There is a special breed of developers that enjoy maintenance of
code, and even a rarer breed of those who enjoy maintaining some one
elses code.  However, a large majority of coders want to work on new
project, work with new technology, using utilities with lots of bells
and whistles.
Copying and pasting an entire application and changing a bunch of
labels isn't as exciting as it might sound… Hacking in a few more
case statements in a ridiculously complex stored procedure in order
to service yet another customer without creating a proper data
structure somehow doesn't seem to fulfill that part of us that wants
to build something that matters.
Design Success Factor - 8:  Include in your design document the
known  possibilities.  The design phase may reveal how technology can
create business opportunities beyond what the stakeholders could
conceive? If you can tie to an core business objective you will at
least be acknowledge. But it's only fair to accept that a majority of
your suggestions will be rejected and a rare minority might make it
into the immediate product.

The design phase is the time to be creative not the build phase.
Developers that make design choices as they go are renegade
programmers and are a determent to the team.  Instead let the
developer have a creative outlet and input during the design phase.
  To create the design document quickly.  Divide the document in
sections.  Develop the sections I parallel and finalize it as a group.

9. Having a Voice
When a developer speaks, someone should listen. When several
developers are saying the same thing, someone should listen and
act...quickly! Developers are in the trenches, and they're the first
ones to know when a system or process is not working.

Design Success Factor - 9:  Include in your issue log, the date and
time it's reported.  Who you notified and the current status.

10. Being Recognized for Hard Work
Recognition is one of Herzberg's core motivation factors and it
applies to software developers as much as anyone else. Software
engineers  love building things that impress themselves, our co-
workers, our bosses and our friends.
Building something great is fun, but it's much more fun when
someone's there to pat you on the back, throw you a party, sing your
praises, or buy you a steak dinner. Most developers enjoy hearing
praise and receiving recognition for hard work, but even the ones who
don't need it are somehow soured when they don't receive it (or worse
yet, someone else receives recognition for your work).
Design Success Factor - 10:  Make your design document a real time,
working document and a development report card.  Check off your
completed task as you go.  Use Red, Yellow, Green to identify what is
on schedule, at risk and behind schedule.


11. Building Software without Meeting Mania
For every page Developers feel wanted to build they had to call a
meeting with six people. Any change to the database required an
additional 3 more meetings and approval by committee. It was nuts,
and applications took 5x longer to build.
The authority to make project decisions without calling a meeting is
huge.
Design Success Factor - 11:  In addition to your issue log, include
the impact of decision delays.  (Ideally, the Project Manager will
have a project issue log and you will just be adding input and
updates where an issue is relevant to the development team).
12. Performance Imperfection
No one likes developing against error prone interfaces, crappy code,
and poorly-designed data models. Too many legacy constraints suck the
life about of software engineers. They are called legacy
liabilities.  Alone they can be ignore upgrade after upgrade but they
have an latent accumulative affect on something stakeholders don't
care about called maintainability however there is a long term side
affect called performance that stakeholders will stand up and take
notice.
Design Success Factor - 11:  The design document should include the
blantant as well as latent `side effects' – including quality,
maintainability, security, performance usability.

What makes a good design?
A design will typically be considered good if it fulfills the
requirements in a meaningful way. If any aspect of the design cannot
be justified, then it is probably worth reevaluating. Many developers
try to incorporate design patterns into their work, and they often
add unnecessary complexity. The design document should be able to
list at least one compelling reason, related to the requirements, for
why a design decision was made. That reason must then be documented.
If the design document can't come up with a clear reason for a design
decision, then it is probably not adding value.
Diagrams are a great tool for visualizing your design, but they
cannot convey the motivation behind your design decisions. That is
why it is so important to let diagrams supplement your design
document, not be your design document.
In addition, it is also extremely important to document any benefits
that result from a design decision. By doing so, others who read your
document will understand what value they can gain. Likewise, any
associated risks must also be documented. More often than not, other
developers have faced the same risks and may have helpful pointers or
solutions that you may not have thought about. By listing these
items, you also get others to think about what the potential risks
could be as well. Remember to make the document a team effort.
Teammates will often be able to see potential pitfalls. It is much
easier to rearrange some boxes in a diagram than it is to rewrite
hundreds of lines of code when an assumption fails or when a
developer hits an unforeseen snare during coding. A good design
document minimizes unexpected complications by addressing them before
the code is written.
Finally, a document will provide you, your manager and your team with
a common vocabulary for talking about the project. A design document
can be a powerful tool for a manager because it gives them a view
into the project that they don't normally have the technical
expertise to see. By listing the benefits you give your manager
tangible items that describe why your design is sound. By documenting
the risks of your design before development, you pass the
responsibility of that risk to your manager, which is where it
belongs.
Lastly, a design document can not be create with out a through
analyst of the requirements document.  If there is a missing,
incomplete, ambiguous, unnecessary or a requirement that isn't
feasible.  The Technical design Document lets the development team to
reclaim their voice, their influence and the destiny of the projects.

Jacqueline Sanders is a 20 year veteran of software development and
an co-author of the 12 Steps to Process Improvement.  Currently she
is a senior instructor for B2TTraining.com.  Visit www.
Intelligentpi.com  or email moreinfo@... for the TDD
templates.

What is SOA governance?

SOA governance is an extension of IT governance that focuses on the
lifecycle of services and composite applications in an organization's
service-oriented architecture (SOA). The function of SOA governance
is to define:

Decision rights for the development, deployment and management of new
services.
Monitoring and reporting processes for capturing and communicating
governance results. Because SOA applications are intrinsically
fragmented, they introduce new governance challenges. But with the
proper policies, principles, standards, procedures and processes in
place, businesses can realize the full benefit of service
orientation. An effective SOA governance platform not only helps
business and IT teams better identify which projects contribute most
to business goals, but it also empowers employees to work and
collaborate more efficiently by clearly defining their roles and
responsibilities.
What is service lifecycle management?

Once the SOA governance framework is implemented, it will be used in
the model, assemble, deploy and manage phases within the SOA
lifecycle. Related to the operational aspects of implementing SOA
governance, service lifecycle management addresses how services will
be developed, deployed and managed.

Service lifecycle management focuses on the development and
deployment of services. SOA governance supplies the decision rights,
processes and policies for those activities. Once a service is
deployed, there must be management aspects in place to control and
monitor the service.

Within service lifecycle management there is a set of functions that
will need to be in place and governed to ensure that the value
proposition of SOA, particularly reuse and cost reduction, is
achieved.

For more information on how to advance your SOA governance
procedures, visit:
ibm.com/software/solutions/soa/entrypoints/advancing_soa_governance.ht
ml

  SOA Quality Management is the next component of SOA Governance and
Service Lifecycle Management

March, 2006 - IBM announced our SOA Governance strategy and direction
and tooling
October 2006 - Service Lifecycle Management was added to detail how
SOA Governance will be operationalized within the SOA Lifecycle.
December 2006 - IBM featured Empowering the `A' in SOA, which
included a number of new and updated products targeted at approach to
Service Lifecycle Management Architecture component.
Today - IBM is adding SOA Quality Management to our SOA Governance
and Service Lifecycle Management
The announcement today focuses on extending the overall SOA
Governance and Service Lifecycle Management capabilities with a set
of new Rational test tools and updates to Tivoli products and GTS
(Global Technology Services) Offerings.

  Why is Governance important to SOA

The increased flexibility and cross-organizational nature of business
services that SOA facilitates, requires that organizations establish
a framework to implement active decision-making, accurate tracking,
improved serviceability and better communication.

SOA governance is the mechanism to ensure that the decision making
structure is solid, relationships between services and parties are
managed and that there is compliance with the laws, policies,
standards and procedures under which an organization operates.

Specifically SOA governance

Creates higher return from focused SOA investments
Aligns IT and business strategies, creates communication paths
Reduces coordination costs: less time wasted due to poorly-managed
conflicts Institutes efficient and effective decision making and
clarity executing roles and accountability Measures effectiveness of
SOA An enterprise that fails to realize the importance of an
effective governance structure may not stand to benefit much from a
SOA transition.

FOR MORE INFORMATION GO TO WWW.IBM.COM

Available on Amazon.com:

Accelerating Process Improvement Using Agile Techniques explains how
agile programming is applied to standard process improvement. By
applying agile techniques, IT organizations can speed up process
improvement initiatives, minimize the resources these initiatives
require, and maximize the benefits of process improvement. The book
details step-by-step how to implement the Accelerating Process
Improvement Methodology (APIM) and how to integrate APIM with various
standard process improvement models and methodologies, including the
ISO 9000 series, SPICE, TQM, SPIRE, PMBOK, and CMM/CMMI. Agile
process improvement enables organizations to rapidly set strategic
goals, meet a greater percentage of user requirements, and realize a
quicker return on investment. About the Author Deb Jacobs is a
Professional Consultant with Focal Point Associates specializing in
process improvement and project management. She currently provides
support to organizations in training, process improvement consulting,
project management consulting, software engineering consulting, and
proposal development. Ms. Jacobs has over 25 year's in project
management, process improvement management, system/software
engineering, and proposal development with a BS in Computer Science.



Also Check Out:

Interpreting the CMMI: A Process Improvement Approach (Hardcover)
by Margaret Kulpa (Author), Kent A. Johnson (

This is called one of the most misunderstood philosophies and
approaches in the IT industry.   This month we will focus on Six Sigma
and present various topics.

One Six Sigma antedote being "You can't improve what you can't measure".

Share you experience with Six Sigma...

A recent survey examined the strategic, day-to-day contributions of
BAs. It identified BAs as seasoned professionals who juggle multiple
tasks (above and beyond just asking question and writing
documentation) and BA's help create IT projects that directly impact
business success. The survey also demonstrated that the BA enjoys
substantial job security, which is particularly important during a
period of high outsourcing.

"The business analyst position is one of the most in-demand jobs in
all of IT," said Paul Melde, Vice President of Technology of
Dice. "Companies are beginning to realize that business analysis is
an essential internal function of an organization and plays a
critical role in achieving business and product development goals."

The Compuware-RQNG survey characterized the BA's role as increasingly
strategic:

#1. More than 75 percent of the time, business analysts are assigned
to projects at or before project initiation, signaling that they are
key influencers on strategic technology decisions.


#2. Business analysts are experienced, seasoned professionals with a
median of seven-plus years in this role, with fully 35 percent having
more than 10 years' experience.


#3. Slightly more than half (50.3 percent) of business analysts earn
$75,000 or more.

Visit www.b2ttraining.com and www.theIIBA.org  to explore BA careers!

“It’s clear that business analysts have an increasingly important role in
helping the IT organization bridge the gap between the business and IT,” said
Mike Burba, Director of Marketing for Application Delivery Management at
Compuware. “At Compuware, we are committed to helping BAs capture better
requirements and collaborate with their stakeholders more effectively.”

Compuware Optimal Trace is Compuware’s solution for business requirements
management. It enables business analysts to capture “structured requirements”
use cases, which is a unique and easy-to-use approach that enables BAs to
capture business requirements from the perspective of the user, complete with
visual storyboards and traceable relationships to business needs.

Complete results from the survey The New Business Analyst: A Strategic Role in
the Enterprise can be found at http://www.compuware.com/thenewstrategicBA.

Requirements Networking Group
RQNG is a community website specifically devoted to the discipline of “IT
requirements management,” targeting business analysts, systems analysts, project
managers, testers and others with requirements gathering and related
disciplines. RQNG focuses on requirements, tools, methodologies and education.
For more information, please

visit http://www.requirementsnetwork.com.

In general, Agile development simply implies a more lightweight
development methodology completed in smaller increments, and
increased face-to-face consultation (BA, QA and developers) on a
daily basis during the life cycle. It is important to note that a
company that uses Agile can still be a "RUP shop" if they decided to
implement a Agile-inspired, lighter version of RUP.

Here's a pretty balanced article on Agile development:

http://en.wikipedia.org/wiki/Agile_software_development

Also, here's a link to some very informal information on Agile by a
few Agile enthusiasts:

http://agilemanifesto.org/

Here's two other, more formal explanations:

http://www.agilemodeling.com/essays/agileSoftwareDevelopment.htm
http://www.stsc.hill.af.mil/crosstalk/2002/10/highsmith.html