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

While leadership is a process, it is a conditional, flexible and
ambiguous process. Being an effective leader as a project manager is
determined in part by our comfort level with ambiguity and our
uncertainty, and our willingness to adopt and adapt given the
situations that we face.

Eliminate the ADMINISTRATIVE HEADACHES

It's the Business Analyst job to capture the requirements for a new
software project and communicate these requirements to the IT team.
But if this is a role that you perform regularly, you'll know that
it's not as easy as it sounds.

The business requirements for large IT projects are inevitably hard
to define. Users may not be able to easily articulate their needs,
and different teams may have different perceptions of the way
processes should work.  Once requirements are captured - the change
management process starts with the challenge of keeping the team
continually updated without overwhelming them with documentation.

What's more, the introduction of new business systems is often the
catalyst for business process change. But getting it right is
essential. The requirements definition not only provides the roadmap
for the software development team, but also creates a framework for
effective quality assurance and testing. If the requirements are
incomplete or ambiguous, problems will occur later in the project
that will be costly to resolve

Contour helps to alleviate these challenges. It allows business
analysts to:

- Create one central repository for all requirements, so that there
is only ever one, up-to-date version of the project specification
- Display relationships between requirements, so that any gaps in
process flows can be easily identified
- Compare different versions of requirements, side-by-side, to
clearly see and assess the differences and changes made
- Create content templates, which speed up repetitive tasks
- Assess the impact of changes to requirements, before making them
and consider `what if' scenarios
- Decompose high-level requirements into individual system features
- Collaborate more effectively with business and IT teams
- Produce reports in a range of formats including Microsoft Word,
Excel and PDF


http://www.jamasoftware.com/screens.htm

Do you have any certifications?  How have they helped you? Do you
think they that certifications are required in order to advance in our
industry? Do you think that certifications are overrated and too easy
for people with no hands on experience to obtain?

The 12 Step Process Improvement Quick Reference Guide helps you fast
track and energize your initiatives allowing your organization to
come up to speed in a short period of time. It can help cut your
ramp up time in half for your process improvement projects. It's an
easy to read, fast and practical introduction that lays the
foundation for a more robust and comprehensive version of 'Feng Shui
for Intelligent Process Improvement'. This pocket size version
contains concepts that will enable you to begin making the necessary
organizational changes that will bring harmony and balance to your
work environment and projects. Our series of books incorporate an
Eastern conceptual approach in order to implement Western models for
process management. The 12 Step Process Improvement Quick Reference
Guide will make an insurmountable difference in any organization
that's wanting to implement process improvement in a radical new
way.

Search on the ISBN#:

ISBN #978-0-6151-5816-7

Cut and Paste the follow link:

http://www.amazon.com/Steps-Intelligent-Process-Improvement-
IPI/dp/0615158161/ref=sr_11_1/102-8105975-5406554?
ie=UTF8&qid=1188922232&sr=11-1

Hello,

The moderator of the IHateMyITJob group has changed the group's name.
This means that both the group's email address and the group home page
location have changed.

The group email address:
ITProFrustratedNoMore@yahoogroups.com

The group home page location:
http://groups.yahoo.com/group/ITProFrustratedNoMore

If you have links which point to this group or an address book entry
for the group, you should update them, as the old addresses will no
longer work.

Regards,

Yahoo! Groups Customer Care

Software Development Professionals are talking a lot about Agile at
the PMI meetings, The IIBA meetings and the SPIN meetings.   Agile
is a new development methodology.  Well to those of us that have
been in the industry for twenty years it's not exactly new.  It's
quite similar to RAD.  The bottomline is that the software
development industry is frustrated with structure methodologies
because they are associated with being slow and rigid.   On the
other hand everyone feels like Agile is chaotic and undisciplined.

What if there is a happy medium?  What if you can have the best of
both words?   This is coming from someone that has actually worked
on two Agile projects but came up through the years doing structure
methods.  At the end of the day there is an approach that allows you
to have the best of both worlds.  What I've observed first hand, is
that you do your Scoping, High Level Defining and Design phases in
the traditional structured method but compress and fast track where
you can.  When you get to the Design and Develop stage you use the
agile methods and approach, interweaving detail requirements
eliciting...

Do you have an opinion on Agile versus Structured development
approaches?

Does this topic interest you?  Does your organization need a way to
streamline and fast track without sacrificing structure....

Let us know and we'll provide more topics and articles on Agile
versus Structure...

We are always open to answering and addressing your real world
questions and challenges!



J. Kay

What does configuration management mean to you?  Does your
organization version control documents and/or source code or both? We
want to here from you!

Greetings BDPA,

The 21st Century has been marked with many great achievements, one
being the inter-mixing of cultures.  Feug Shui for Intelligent
Process Improvements continues that trend by incorporating Eastern
techniques with Western technological approaches.  Learning as we
know it changes everyday with emphasis on diversity and immersion.
I implore you to visit the Feug Shui for Intelligent Process
Improvement's website to view the latest in technical literature and
to see how embracing another culture's practices can make an
insurmountable difference in understanding our similarities as
humans.

In the spirit of harmony,

VLee/JKay


Intelligent Process Improvements(IPI), LLP
"Promoting Harmony & Balance with Business Best Practices"
www.IntelligentPI.com

Attention Business Analyst & Quality Analyst: Get certified, enhance
your resume, be better prepared for interviews. Improve your salary
and career potential with a Business Analyst, Quality Analyst
Certificate in Process Improvement. Take our Online Training Course,
pass the test at the end and we'll send you a Process Improvement 101
Certificate. Go to www.intelligentpi.com or email us at
moreinfo@...

The SEI announces the publication of CMMI for Outsourcing:
Guidelines for Software, Systems, and IT Acquisition by Hubert F.
Hofmann, Deborah K. Yedlin, John W. Mishler, and Susan Kushner.
Published by Addison-Wesley, this book is part of the SEI Series in
Software Engineering.

This book is a practical introduction to the initial draft CMMI for
Acquisition and to its use in all phases of technology acquisition.
Developed under the leadership of General Motors (GM) and the
guidance of the SEI, this initial draft combines CMMI's successful
process discipline with techniques proven to work in GM's own
extensive outsourcing program. This book covers the entire
outsourcing project lifecycle, presents real-world stories as they
might occur in organizations, and includes insider experiences,
tips, tricks, and pitfalls to avoid.

The topics discussed in the book include the following:

determining when outsourcing is and is not appropriate
developing outsourcing strategies and aligning organizational
structure with them
capturing accurate requirements
specifying realistic design constraints
writing effective RFPs
selecting, managing, and collaborating with suppliers
negotiating contracts
managing risk
measuring for success
For more information, see the Addison-Wesley book page at
http://www.awprofessional.com/title/0321477170.


http://www.sei.cmu.edu/news-at-sei/whats-new/book-cmmi-
outsourcing.htm

May 24, 2007


Too many companies have trouble seeing the relationship between I.T.
and business processes.
By Michael Vizard



You can't manage what you can't see, and even if you can see it,
that doesn't necessarily mean you understand it. One of the
overarching problems with I.T. today is that no company can make a
business decision of any merit without kicking off some sort of
related I.T. process. But truth be told, very few organizations have
a real handle on the relationship between a business process, such
an order to cash, and the underlying I.T. systems that power this
type of transaction. And worse yet, if they did have visibility into
the process, they would probably discover that they have four sets
of different systems handling overlapping business processes.
The end result of all this confusion is that most senior I.T.
executives can't really have a candid conversation with their
business counterparts about what the real I.T. costs will be when
somebody proposes a new business process. The standard default
response is to frantically find some sort of reference model in the
suite of SAP or Oracle applications that approximates what the
business wants to do, and then try as hard as possible to make the
business process bend to meet the capabilities of the software when
what the business needs is for the software to bend to the
requirements of the business. After all, if what you're doing is
merely a slight variation on the business processes as coded in the
SAP or Oracle applications that every one of your competitors is
using, it becomes pretty hard to argue that your I.T. investments
are strategic.

ADVERTISEMENT The biggest problem most organizations face when
trying to align their I.T. investments more closely with the
business is getting their arms around what they have. In a business
context, this means not just having an asset management system that
tracks how much hardware you have and the number of software
licenses you need. It means having a modeling system where you can
create what-if scenarios that show the relationship between new
application requirements and the underlying I.T. infrastructure. For
example, if the company wants to create a new set of business
processes, I.T. people should be able to closely approximate the
impact that those new processes will have on the technology
infrastructure so they can identify the corresponding requirements
and costs associated with those business processes.

That may sound a little far-fetched, but that's exactly what the
I.T. people at Warner Bros. have built, using process modeling
software from Troux Technologies. As vice president of technology
architecture and planning for Warner Bros., Doug Russo has a
singular passion for doing the underlying forensics work that allows
his company to literally visualize its enterprise architecture and
associated business processes. He does this by first capturing, in
the Troux software, knowledge from members of the I.T. staff about
systems associated with specific business processes; Russo then
links the modeling package to various asset and network management
systems to keep the model updated on a daily basis.

This is no simple undertaking, and the Troux software is not some
sort of silver bullet that automates the process of collecting all
this information. It still takes months to compile all the necessary
data. But what Troux does provide is a tool that allows senior I.T.
executives and their business counterparts to make sense of all the
data. This in turn takes out a lot of the guesswork associated with
trying to understand the impact that new sets of processes are
likely to have on the I.T. infrastructure, so a proactive plan with
real actionable steps can be developed—in contrast to putting in a
reactive strategy that relies heavily on application accelerators
and other black-box devices to compensate for unforeseen pressure
being brought to bear on network, server and storage infrastructures
that were pretty fragile to begin with.


And on a personal level, it allows senior I.T. managers to look like
they have some level of command over their operations, instead of
hoping that vague answers packaged around technology buzzwords don't
give away too much about how little control they have over I.T.
within the company.

The opportunity here is to take the whole I.T. conversation to a
higher level, because now you start to think about what it might
take to customize a piece of software to extend a business process
without necessarily having to fear that the entire I.T.
infrastructure might collapse under its own weight. After all, isn't
this what everybody has really been saying all these years when we
talk about the need to have tighter integration between I.T. and the
business?

Greetings,

Intelligent Process Improvements LLP is proud to announce the
following updates for the month of May:

1. IPI to be featured as guest speakers at SPIN (nationally recognized
     PI organization)
2. IPI receives first INDUSTRY royalty deposit
3. IPI is listed in New Book Showcase Catalog
4. IPI will be on display at the National Book Expo in New York June1-
3
5. IPI website completed
6. V. Quan Lee nominated for an award for the NJ SPIN chapter
7. Morgan State University Professor requests to have V. Quan Lee for
     speaking engagement for fall semester

For more details go to www.intelligentpi.com!

If you are interested in the book, our consulting services or our
template library please email moreinfo@...

Send us some urls of your favorite Software/Computer/IT/Process
Improvement websites!

There is still time to pre-order and be one of the first to get your
copy of the book that introduces Feng Shui to Software Development in
order to make this industry less stressful and to cut down on turn
over.  Go to our website at www.intelligentpi.com  to order using
Paypal!!!

We are excited about the responce to our pre-order campaign and did
not anticipate the enormous amount of word of mouth endorsements.
Thanks to all of our many colleagues for their support...  We tried to
acknowledge you all, so make sure to get a copy so you can see your
name!!!

What do you hate (or just dislike) about your current job in software
Development?

Visit www.intelligentpi.com.... pre-orders will start May 1 for our
315 page book...it's an easy to read, even entertaining do-it-yourself
guide to process improvement... an industry first...

Enter your vote today!  A new poll has been created for the
IHateMyITJob group:

What is the most stressful aspects of your job? What do you hate the most?

   o Not Being Paid What Your Worth
   o Deadlines
   o Resources
   o Management
   o Lack of a Challenge


To vote, please visit the following web page:
http://groups.yahoo.com/group/IHateMyITJob/surveys?id=2478893

Note: Please do not reply to this message. Poll votes are
not collected via email. To vote, you must go to the Yahoo! Groups
web site listed above.

Thanks!

Numerous surveys and studies confirm that occupational pressures and
fears are far and away the leading source of stress for American
adults and that these have steadily increased over the past few
decades. While there are tons of statistics to support these
allegations, how significant they are depends on such things as how
the information was obtained (self-report vs. answers to carefully
worded questions), the size and demographics of the targeted group,
how participants were selected and who sponsored the study. Some
self-serving polls claiming that a particular occupation is "the
most stressful" are conducted by unions or organizations in a
attempt to get higher wages or better benefits for their members.
Others may be conducted to promote a product, such as the "Stress In
the Nineties" survey by the maker of a deodorant that found
housewives were under more stress than the CEO's of major
corporations. Such a conclusion might be anticipated from telephone
calls to residential phones conducted in the afternoon. It is
crucial to keep all these caveats in mind when evaluating job stress
statistics.


http://www.stress.org/job.htm

John Mizhir quit the legal profession in fall 2003 because he
loathed his $185,000-a-year job at a huge corporate-law firm in San
Diego. He trumpeted his decision to become a real-estate developer
with an e-mail dispatched to more than 600 associates and
friends. "I didn't want to do law anymore," he recalls.

Several months later, though, he resumed practicing law -- as a solo
attorney. He relishes the freedom to choose his hours and his
clients, who are mainly entrepreneurs and small firms. "You're their
knight in shining armor," explains Mr. Mizhir, now 32 years old. He
also runs a real-estate investment, development and brokerage
business. "For the first time in years," he says, "I'm truly happy."

Many people belatedly realize they hate what they do for a living.
As the economic recovery gains momentum, more job hunters will seek
greener pastures in a different field. But it's risky to abandon
your secure professional identity, especially when the chosen
alternative fails to cure your work malaise.

Before changing livelihoods, diagnose your occupational ills. "Is it
the work? Is it the people? Is it the context?" advises Herminia
Ibarra, author of a book on career reinvention and an organizational-
behavior professor at Insead business school in Fontainebleau,
France. Without a good grasp of their situation, people often
make "what they thought were big changes and end up in the same kind
of setting," she believes.

Don't soul search alone. Ask your employer, local community college
or public library to conduct and analyze evaluations of your
personality traits and work style. The tests should reveal whether
you like working in a small group, favor creative tasks or prefer a
fast pace.

A personality assessment confirmed Ira Wolfe's hunch that he should
leave dentistry. His routine dental duties were boring him so much
that he taught himself to be ambidextrous. But he lacked passion for
other professions, such as funeral director, that the assessment
concluded might suit his temperament better. "I didn't know what I
wanted to do differently," Dr. Wolfe remembers.

The dentist finally sold his flourishing practice seven years later.
He now offers career and pre-employment testing for a
living. "Instead of reading X-rays, I read personality profiles,"
says Dr. Wolfe, founder and managing partner of consultants Success
Performance Solutions in Lancaster, Pa.

A counselor helped Mr. Mizhir to rethink his escape from the law. He
had attended law school mainly because his father, a small-town
attorney, "wanted me to follow in his footsteps," he says. He worked
for three successively bigger law firms, lasting just 10 months at
the last one. Upset that corporate clients barely knew or
appreciated him, "I lost my drive," he says.

Mr. Mizhir turned to a business coach after he quit. At the coach's
suggestion, the young lawyer compiled a list of his talents and the
worst aspects of his prior job. He gradually realized that "it
wasn't the law I disliked," he recounts. "It was working for a big
law firm."

In exploring a professional switch, you also should enlarge your
personal network. "Share your story with everyone you encounter
since the most important contacts can often reside in the least
likely of places," suggests Frank Webb, co-owner of a New York
interior-design firm and a former investment banker. He met his
current business partner in their apartment-building elevator when
they swapped war stories about renovating their residences.

It's equally important to get real-world exposure before you plunge
into a new way of making money. "Seek out people already doing it so
you can fully understand the implications," recommends Jim Atkinson,
a regional vice president in Cleveland for Right Management
Consultants, outplacement counselors. Mr. Mizhir, for example, spent
hours talking to real-estate brokers and developers about what they
liked and disliked about their jobs.

Taking classes, doing freelance work or serving as a volunteer will
generate further insights. But there's a less time-consuming way to
flirt with another occupation: Shadow a seasoned practitioner during
your vacation.

A Portland, Ore., concern called VocationVacations will arrange
a "dream-job holiday," matching you with individual experts engaged
in more than 40 different vocations here and abroad. Each tryout
generally lasts a few days and costs between $349 and $2,000.

You can sample everything from architect to cowboy-boot maker and
golf pro to zookeeper. A Los Angeles lawyer did a one-day stint as a
dog day-care business owner.

Nearly a third of the roughly 70 participants so far have been
people "taking the first baby step" toward a career change, says
Brian Kurth, owner of VocationVacations. He launched his enterprise
last year following product-marketing stints with a telecom giant,
dot-com and vintner. "You test drive a $35,000 car," he
observes. "Why wouldn't you test drive your dream job before you
quit your day job?"

Email your comments to cjeditor@....
http://www.careerjournal.com/columnists/manageyourcareer/20050413-
managingyourcareer.html

Flexible Processes....

the CMMI alternative.....    www.intelligentpi.com

Like to know what are your thoughts about an SDLC's effectiveness.


I would think to some degree it relates to the team size: more
people involved, the more you need SDLC so everyone can follow a pre-
conceived process without bickering about who should do what next
(or do you disagree?)  It's great to have CMMI and RUP (and the
likes) to follow but do people really use this stuff and produce
better systems?

Is SDLC helpful or is it just a nice idea that no one really
follows? JJ


"Is SDLC helpful or is it just a nice idea that no one really
follows?"

What' the alternative to having a System Development Lifecycle?

Show up to work and just start writing code? What are you writing?
What is it supposed to do? How do you build it? When you're done
coding it, does anyone else get to look at it or do you just put it
on the "live" box and call it a day? Are you testing it? Are other
people testing it? (I could go on all day.)

"SDLC" is a very generic term.

Picking the proper SDLC for your environment, team, and company is
important. Check out the book, Rapid Development by Steve McConnell.

Good luck! Michael Sica



I think its a good question to ask.

While all this SDLC, RUP, CMMI etc are useful, I feel these are
things that people already know.
Everyone knows that to start writing code, you need to know what to
code, therefore - business analysis.  The key is, how effective we
are in gathering the requirements. And this applies to how effective
we are in coding, testing, implementing  etc  I don't believe that
having a huge model pasted on the wall to remind you of what SDLC is
going to help in that. dot




big plug for Rapid Development by McConnell. It really talks about
how doing all the basic things will help you develop software
quicker as opposed to taking short cuts.

I agree whole heartly about Requirements being key. I'm on a project
now where Analysis and understanding of the problem was VERY weak.
Hence, the project is about 10 months overdue. No this isn't my
fault, just bad requirements. Patrick




If you're interested in what processes (or parts of processes)
developers actually follow, and which make a difference to project
outcomes, check out the work of Alistair Cockburn
(pronounced 'Coburn').  He's spent 10 years reasearching exactly
those questions, and I think the answers he's come up with are good -
  i.e. they are consistent with what most good developers would say.





thank you for your ideas and comments.  Personally I think it's
almost always good to keep groups small.  Even if you're working on
some big projects, it's always better to break it into a size where
a small team can work on manageable parts.

That's why I question the reach that something like CMMI is trying
to achieve.  to overlay a very verbose very methodical process to a
big project is, imho, never as good as breakup the big project into
sizeable chunks and have small teams work together under a simpler
sdlc process..... JJ

There are two ways of looking at this. You could look upon the
perfect IT project as one where you got lots of money for doing very
little work, but we will concentrate here on what would make a
project successful and enjoyable to work on.

All Requirements Gathered

When I worked at American Express, in looking for a new methodology
that would fit their purposes, I went round asking the IT department
managers what they wanted from a new methodology. They replied that
the biggest problem that they had was in getting the requirements
phase right. There were a number of reasons for that.

The prefect project would have buy-in from senior management that
the correct business users would be provided, and if they cancelled
a requirements gathering meeting, especially if they were just one
of several crucial people attending the meeting, that they would
have to answer to the senior management project sponsor.

A list of all the right people would be put together between the
project and the project sponsor, with the help of area management.

Good techniques like Use Cases or Event Modelling would then be used
by experienced business analysts to gather all the requirements.

The project sponsor would then make sure that there were no delays
to the business users signing off on the project, which can cause
massive delays and large costs against the project.

Change Management

A project need not remain static in terms of requirements. The
business doesn't remain static. Changes, which are being
incorporated into the current system to enhance the business, need
to go into the new system too.

However, it should be understood from the start that these should be
kept to a minimum, and that there will be consequences in terms of
budget and time if any new changes are to be included.

On the perfect project, time would be allocated in the beginning for
a certain amount of business changes to be incorporated in the
requirements. This time would be separate from contingency time.

Estimating

Most projects are scuppered before they start due to poor
estimating. What normally happens is that the estimators say "that
will take 7 days and that will take five". It is totally
unscientific. The total estimate, which does not take enough account
of time needed for management and co-ordination, is then further
reduced after pressure put on by suspicious management who want to
meet certain budget and time deadlines.

On the perfect project, the estimators would know the productivity
of the company on previous projects, and the individuals on it. They
would know the productivity to be expected when using the languages
and tools being used on the project. They would use a scientific
measure like Function Point Analysis to determine the amount of
functionality on the project. They would also know by how much
functionality had increased in previous projects from the initial
estimate to the final implemented system.

They would use this information to create an estimate for the
project and the individual parts of the project that can be met.

Tracking

Normally projects go horribly wrong here. Project management seldom
know the real status of the project. It is too easy for people on
the project to hide, at least in the initial stages of the project,
the fact that they are behind. When they get behind on one task,
they say on their weekly timesheet that they are more advanced than
they actually are. When they find that difficult to hide, they start
allocating time to tasks they have hardly started.

The project manager comes around each week to track progress but he
is given duff data. He or she passes on duff information on project
progress to senior management who think everything is going well –
as it always does in the first few months of a project.

Why they never learn, I don't know, because the same mistake is
being made on project after project on companies up and down the
land.

A good project would micro manage tasks, with those tasks split into
smaller tasks of bite size proportions. There should be no 85%
finished. No time should be considered to have been spent on a task
till the whole task is completed – and this should be easily
provable.

The perfect project, however, would track completely differently.
Time deadlines are too threatening and are bad for project morale
especially when the deadlines are too tight. Some psychology should
be used here.

On the perfect project, no time deadlines should be set at all
(although, of course there would be a project plan known only to
management). Instead, developers should be told that a particular
piece of work contained, for example, 20 Function Points, and the
developers normal delivery rate was 20 function Points a month. In
this was, each piece of work handed out to a developer would be a
challenge to them to better themselves and outdo what they've done
in the past, rather than a threat.

It has been proved in the past that developers are measurably more
productive when there is no estimate for a piece of work at all.
Indeed as soon as a time is allocated for a piece of work, that
becomes the minimum time and is no longer an estimate.