Steps to a Hassle Free and Effective

Software Development Project

By Executive Brief Staff \\ July 2008

Following these nine steps may be the ultimate secret weapon to winning business
and successfully delivering new easy-to-use software that meets and exceeds
expectations.

Has your company developed entirely new software or added to software already in use
throughout the organization and found the process cumbersome, frustrating, and
sometimes not living up to expectations or meeting organizational goals? If so, the
solution to a smooth and effective development program may be as easy as staffing a
well-qualified project manager and adopting a proven development process.

For any software development or other project initiative your company may be
considering, it is critical to have in place and practice a set of effective and proven
guidelines to ensure project success and delivery of the expected results: taking into
consideration the role and responsibilities of a well-qualified project manager, knowledge
of important business and financial aspects, and a step-by-step process that all contribute
to the solid foundation and implementation of an effective project plan.

Developing a Practical Approach: The Role of the Project Manager

When undertaking a software development project, the first element to consider is the
establishment of a comprehensive yet practical approach to the initiative that ultimately
will lead to a successful end result.

The in-house project manager has a key role in ensuring each phase of the project is
carried out as planned. The project manager is responsible for considering the potential
risks involved with the project and how to avoid and resolve them, establishing and
maintaining momentum throughout the project, ensuring individual project team member
tasks are assigned appropriately and carried out according to specifications, and
successfully addressing and resolving any conflicts that may arise during the length of the
development project.

A well-qualified project manager is able to address what may seem to be an

overwhelmingly complex process by developing an organized project management
approach where the process is broken down into manageable individual tasks and
understanding how to keep those involved in the project dedicated to the ultimate goal of
meeting and even exceeding the expected end result.

If the software project manager dedicates the necessary time, effort, and resources to the
preparation of an efficient, comprehensive, and practical approach, then the project team
may progress with ease and confidence as they deliver on their individual tasks, having a
solid foundation and strategic framework at the outset. Far too often, however, failures
with such projects are the result of not only a poorly executed project management plans,
but one that ultimately lacked the fundamental elements of a well-though-out approach
rooted in adequate preparation and commitment from the project manager and project
team.

Designing a strategic project manager plan means taking into consideration all aspects
that can contribute to success or potential failure.

Embarking on the Initiative: Key Steps to Consider

With a comprehensive approach and a competent project manager in place to guide the
new software development initiative, there is another important element your
organization may find helpful as you embark on the project: establishing specific steps
that can be followed to project completion that are based on proven industry experience
in such a project environment.

Following are a set of practical guidelines to approach a software development project,

established by two university professors and business consultants with specialized
expertise in the computing, engineering, and general business environments.

Dr. Gordon Scott Gehrs is an adjunct instructor at the Illinois Institute of Technology
(IIT) and a business consultant for the Jules F. Knapp Entrepreneurship Center at IIT. Dr.
Dorota Huizinga is associate dean of the College of Engineering and Computer Science
and a professor in the Computer Science Department at California State University,
Fullerton, as well as a frequent business seminar speaker, a business consultant, and co-
author of Automated Defect Prevention: Best Practices in Software Management.

Read on for nine key steps to consider as you embark on a software development project.

Step #1: Conduct Feasibility Analysis

According to Dr. Gehrs, a critical first step is to interview stakeholders in order to

uncover whether a specific need exists, identify this exact need, and determine whether
the proposed project can feasibly deliver the expected software development. “Many
times, this is the point at which an ROI study will be carried out in order to determine
project costs and benefits,” says Dr. Gehrs.

Step #2: Analyze and Determine Requirements

When it comes to the next step of determining requirements, Dr. Gehrs believes a proper
analysis should consist of interviews with end users and others who will be associated
with the new software system. In addition, a thorough review and a keen understanding
of user documents, business rules, and processes are keys to determining appropriate and
necessary features and functionality. This is a valuable and significant step in the
development process and the point at which such deliverables as those documents
outlining the scope of the project and those detailing the software product requirement
will be produced.

Dr. Huizinga notes the importance of having the minimum technology infrastructure in
place before beginning a software project, which include:

1. Desktops for development with an advanced integrated development environment

suite.
2. A server with a configuration management system for document tracking and
version control.
3. A staging server for integration testing and a production server for deployment of
the final product.
4. A requirement/task/defect tracking tool.
5. An automated build system.
6. A regression testing tool.
7. An automated reporting system.

“Investing in the proper infrastructure is essential and will pay back quickly,” asserts Dr.
Huizinga. There are three key elements the proper infrastructure provides:

1. Product and project visibility

2. Automation of repetitive and mundane tasks
3. Facilitation of collaboration

Step #3: Consider Industry Best Practices

When defining a software development process, consider proven industry best practices.
Dr. Huizinga recommends a good, customized Agile process with emphasis on pictorial
documentation both for requirements and technical documentation. It is important to
follow a standard template and all activities should be traceable through a
requirements/task/defect tool and shared document repository.
Step #4: Design

During the design phase, the software architect, programmer, and/or developer may put
together a detailed design document outlining exactly how the software will meet the
specified requirements. Dr. Gehrs recommends the use of mock-ups to accompany the
design document as a way of illustrating user-interface elements.

In some cases, customization is required in order to meet specific, individual project

needs. For example, Dr. Huizinga notes that this might include the use of specialized
COTS (commercial off-the-shelf) hardware and software components. The wide
spectrum of products from databases to game engines is dictated by the market shift to
customization of existing commercial applications to fit project needs rather than in-
house development of such systems. According to Dr. Huizinga, COTS can offer higher
quality because they are developed by vendors who specialize in systems that provide the
required functionality and are well-tested by many users.

Step #5: Measuring and Tracking Progress

Without the proper technology infrastructure in place, it is difficult to collect and measure
key project data. “Consequently, the software projects cannot be managed effectively,”
says Dr. Huizinga. Project indicators can help to ensure the prompt identification of
potential or existing problems, therefore allowing them to be recognized and remedied in
a timely manner. When observed over an extended period, notes Dr. Huizinga, these
indicators can be used to determine product quality and deployment readiness.

Step #6: Development

At the development phase, the design document is translated into a real piece of software.
When prior careful planning has been executed, the software will match the requirements
of the business driver that initiated the need for the project. Dr. Gehrs points out that
development cycles may produce several versions of the software:

• Alpha: preliminary feature/functionality only

• Beta: used for internal testing or usability testing
• Release Candidates: usually a very stable build that may need minor tweaks
• Production Build or Gold Master: ready for release.

Project managers need feedback on the user’s navigational experience, task-completion

times, ease of use, and other information related to the user interface and user-centric
elements.
Step #7: Addressing Automation

Another key step is to ensure the automation of repetitive tasks:

• Code builds;
• Static code analysis scans;
• Regression tests;
• Collection of project- and product-related measures.

Dr. Huizinga believes that taking such measures reduces the error-prone human influence
when the software is implemented. It also facilitates the use of best practices and
collection of project-related data. “All repetitive and mundane tasks should be automated
whenever possible in any portion of the software life cycle,” she adds.

Step #8: Testing

As the project continues on through each project phase and on to testing, a general
progression of action is as follows: software features are laid out in some sort of list,
scripts are written for each task the user might perform, and those features are tested to
ensure they function properly. Dr. Gehrs points out that testing also may vary quite
widely depending on the individual testing procedures adopted by the organization.
Testing can consist of several sub-stages as well, such as quality assurance and staging.

Once the software is in general use, any bugs found at this point are addressed based on a
criticality scale: urgent fixes are scheduled to be carried out as soon as possible. In
addition, feature enhancements/changes may be slated for future upgrade versions.

Step #9: Gradual Implementation Practices

“Incremental implementation of the above practices is critical to success. The approach

of gradually introducing change group by group and practice by practice is essential to
achieving the desired organizational culture change, as change is unsettling, and there
will always be some degree of resistance,” points out Dr. Huizinga. Because of the
complex nature of software projects and the technology involved, new software
development warrants this systematic approach.

Understanding the role of the project leader and importance of having well-thought-out
development processes in place may be a company’s only real competitive advantage in
an increasingly competitive marketplace. It is the ultimate secret weapon to winning
business and successfully delivering new easy-to-use software.

With workable and disciplined software project guidelines and well-qualified project
managers, your organization can’t lose.
Waterfall, RUP and Agile: Which is Right
for You?
By Serhiy Kharytonov, EVP Consulting Services, SoftServe © 2009 \\ December 2009

Streamline production with fast, effective Waterfall, RUP and Agile processes. Use
mixed software development strategies to meet specific project needs.

Despite signs of life in the economy, the realities of software development persist. Most
companies and customers need their software yesterday with the most advanced features
at the lowest possible cost. To accomplish these seemingly contradictory goals,
developers seek to streamline production with fast, effective processes that can give the
customer what he/she wants in the shortest time possible.

These realities and past development failures have led to a shift in software development
thinking from the more structured, sequential methods of software development of the
past, often called the "Waterfall" model, to more iterative and incremental models such as
the "Rational Unified Process (RUP)" and "Agile."

Agile proponents abound and it can sometimes seem as if more traditional development
processes have fallen out of favor, but in reality all three models have their plusses,
minuses and ideal project environments. At the end of the day, the best method or
blending of methods for you depends on a thorough understanding of all three processes
and how they fit your software project, business culture, and development environment.

Waterfall

Waterfall programming is a highly structured process that relies heavily on up-front

planning and a set of sequential, prescribed steps that flow into each other like a
waterfall. Each step typically has its own team of experts and carefully scripted
milestones and no step can begin until the previous step has been completed. The goal is
to gather all your detailed requirements early in the process and provide a single complete
solution with results that are highly predictable.
Typically the steps in Waterfall development are:

1. Requirements and specifications gathering

2. Software design
3. Coding
4. Integration
5. Testing and debugging
6. Installation
7. Maintenance

Waterfall development can work very well for complex, mission-critical applications that
interface with many other systems and for organizations such as NASA or the military
that require the highest levels of fault tolerance.

Detractors say that Waterfall simply takes too long and lacks the flexibility -- or agility --
required for today's fast-paced software market and development environment. Waterfall
projects typically take months or years, and by the time they're finished, it's sometimes
found that the requirements have changed or that the original requirements were off the
mark to begin with. The result can be expensive, budget-busting fixes.

RUP

Like Waterfall, the Rational Unified Process (RUP), originated by Rational Software and
later by IBM, is also process heavy, but is an iterative approach that takes into account
the need to accommodate change and adaptability during the development process.

Like Waterfall, RUP has a series of phases and milestones that flow into each other.
Phases consist of:

1. Inception, where the project's scope, estimated costs, risks, business case,
environment and architecture are identified.
2. Elaboration, where requirements are specified in detail, architecture is validated,
the project environment is further defined and the project team is configured.
3. Construction, where the software is built and tested and supporting documentation
is produced.
4. Transition, where the software is system tested, user tested, reworked and
deployed.

RUP also defines the roles and activities of team members in depth and relies at each
stage on the production of visual models, which are rich graphical representations of
software systems, and specific use cases rather than the large amounts of documentation
required for each stage of Waterfall. All team members have access to the same large
knowledge base of guidelines, templates, tools, and other items to ensure that they share
the same language and perspective on the project.
While it appears similar to Waterfall development at first glance, RUP's biggest
difference is its iterative development approach, which builds the product in several
stages based on frequent stakeholder feedback. Early RUP iterations are mostly about
defining requirements and architecture and exploring different ideas, while later iterations
attempt to put together a complete product. Each iteration is an executable release and
each RUP phase can interact with previous phases to adapt as necessary.

Not only is the RUP process iterative as a whole but RUP also assumes that each phase
will have several internal iterations based on user feedback.

RUP addresses many of the criticisms of Waterfall development and is a good method for
government agencies and educational institutions that value a stable and repeatable
software development cycle, as well as for organizations that offshore projects to
countries such as India and China, or produce packaged software releases.

Critics say that RUP is still not as quick and adaptable as other methods, such as Agile,
and doesn't work well when fast time-to-market is crucial or for Web 2.0 and Software-
as-aService (SaaS) environments where frequent updates and feature additions are
expected.

Agile

While Waterfall and RUP lean towards predictability, the overarching goals of Agile are
speed and adaptability. There are many different types of Agile development processes,
including XP and SCRUM, but all of them strive to get a basic but functional product
release into the hands of the customer as quickly as possible.

They then follow that release with incremental releases that add and change features as
necessary over time to provide a more robust product. Each incremental module is
planned, coded, tested and completed over short two to four-week sessions. While the
Agile process is scripted like Waterfall and RUP, it emphasizes people and collaboration
over the process itself.

Rather than depending on many teams of experts, the entire Agile development process is
typically undertaken by a single, small, cross-functional, supposedly self-organized team,
that must include a customer representative, who attends daily meetings and makes sure
the team is working on the things the business truly needs. Constant face-to-face
collaboration is the goal, with the customer rep serving as one of the most important
collaborators. Documentation is de-emphasized compared to Waterfall and even RUP in
order to get something out the door as quickly as possible.

With its modular, incremental, collaborative approach, Agile is quick and highly adaptive
to changing needs and competitive challenges, which is why it has so many proponents.
British Telecom is frequently cited as a large company that has used Agile programming
very successfully, with 30 to 90-day development cycles that have yielded dramatic
productivity and business benefits over the 18 or more months it took in the past to
produce useful software.

But while it's easy to fall in love with Agile, it also has its limitations and drawbacks. Its
emphasis on daily in-person meetings and close collaboration makes it difficult to adapt
the process to development outsourcing, clients and developers separated geographically,
or business clients who simply don't have the manpower, resources or interest to spare.

Its emphasis on modularity, incremental development, and adaptability doesn't suit it

easily to clients who want contracts with firm estimates and timetables. Its reliance on
small self-organized teams makes it difficult to adapt to large software projects with
many stakeholders with different needs and neglects to take into account the need for
leadership while team members get used to working together.

Further, lack of comprehensive documentation can make it difficult to maintain or add to

the software after members of the original team turn over, and can lead to modules with
inconsistent features and interfaces. Lastly, more than with Waterfall and RUP, Agile
development typically depends on the ability to recruit very experienced software
engineers who know how to work independently and interface effectively with business
users.

The best of all worlds

If Agile, RUP and Waterfall models have their drawbacks, then which should you
choose? Increasingly, the secret to successful software development is to understand all
three processes in depth and take the parts of each that are most suited to your particular
product and environment. Then, stay agile in the approach to the process itself, constantly
looking back, re-evaluating and revising the development process until it fits your current
circumstances most successfully.

For example, if you're developing SaaS or Web 2.0 software in a highly competitive
market, then you'll probably do better leaning towards Agile methodologies. SaaS lends
itself particularly well to Agile since it provides for constant access to the software to add
or change features. In such a competitive market with changing user requirements you'll
probably want to be able to make changes fast.

On the other hand, if you're producing medical, engineering, or other systems that require
a high degree of design and predictive certainty, then it seems logical to start with
Waterfall.

If you're producing a packaged consumer software product, with new versions that need
to be leaps ahead of previous versions, then your process should probably lean towards
RUP, with some kind of careful requirements gathering, scoping and wireframing process
at the outset, as well as prescribed standards for navigation, look and feel.
However, developers can then use Agile techniques to present frequent prototypes and
incremental modules to the company's product managers to ensure they're on the right
track. The frequency and intensity of collaboration between product managers and
developers really depends on their close proximity and company culture -- whether these
teams are used to such collaboration. When geography is a problem, collaboration tools
such as Web and video conferencing can be a big help.

The same blending of techniques can be used in a corporate environment outsourcing

development overseas. In fact, with potential time and cultural disconnects, it's important
to build in as many iterative and incremental steps and as much ongoing contact as is
feasible for your project and your company's and your development partner's culture.

Whether you want to go with self-organized teams or a more top-down management

approach really depends on the skill level and seasoning of your developers. Many
projects may require a leader who can add some urgency, guidance and risk management
to the project at the outset until team members get accustomed to working together. Then
the leadership role can be scaled back as needed with subsequent increments.

The point is that there probably is no perfect process for all projects and environment, or
even for a single one. That's why companies need to build in frequent "lessons learned"
meetings to evaluate and revise the process itself, which may move more towards one
end of the spectrum or the other at different points in the development cycle. In short,
when choosing between Agile, RUP and Waterfall, adapt the process to your needs,
rather than adapting your project to the process.

The article was first published by ebizQ

About the Author

Serhiy Kharytonov is the EVP, Consulting Services at SoftServe

(http://www.softserveinc.com), a global company providing commercial software product
design, development, testing and lifecycle services to Independent Software Vendors and
building foundational strategic technologies for enterprise clients. Serhiy has been with
SoftServe since 2000, previously in the positions of Vice President of Technology and
Vice President of R&D Services. He holds Master’s Degree in Computer Science from
the National Polytechnic University, Lviv, Ukraine, and is currently finishing his PhD.
Methodology vs framework - why
waterfall and agile are not
methodologies
There are often fights amongst people in the IT profession about whether the 'waterfall
methodology' will or won't work. Over coffee friends and colleagues discuss why the
'agile methodology' is better, or alternatively, too hard to implement. It's also common
for selection criteria to frame questions such as these (taken from real selection criteria
and job descriptions):
"Experience in or an ability to acquire knowledge of software development
methodologies (such as Agile development, Model Driven Architecture,
etc.)."

"Application of a recognized software methodology (e.g. UML) to the design

and development of embedded systems..."

It is shocking that intelligent, well educated people don't know the difference
between a framework and a methodology. It's also shocking that prominent and
respected organisations display this same ignorance. Who cares? Is this a
semantic argument? No, this isn't a semantic argument and the difference
between the two is an important distinction. It's important because a framework
allows you to be loose and flexible; to have 'poetic license'. A methodology is
much more prescriptive. Both can be handy at different times. But a
methodology, is generally better and I'll show you why.

Definition of framework

The Federal Enterprise Architecture Framework defines a framework as:

"A logical structure for classifying and organizing complex information."

Generally within the software lifecycle realm, a framework is a picture or a model

that guides you to understand which artefacts you should produce when. It
doesn't tell you what to do though. For example, typically the waterfall framework
begins with analysis as the first stage of software development. But it doesn't tell
you how to do that analysis. Even if the framework is detailed enough to specify
the template you should use, it won't tell you how to populate the template. Often
though, a framework won't go into that much detail, giving you lots of flexibility to
choose how you're going to do that stage.
Flexibility is a guise though. Ambiguity is another term for it. You aren't
compelled and guided to produce specific artefacts according to a process.
Instead you are left to fumble your way through, trying to apply some kind of
structure. This means that you will inevitably make different choices from your
colleagues who are using the same framework. If your organisation only has a
framework to guide its employees, there will be a lack of consistency. The
problem is compounded when people think they have a methodology and all they
have is a framework. As you can see in the quotes above, they employ people
based on the wrong premise and they also loose faith that a methodology will
guide them. They also start to argue about one framework being better than
another, when what they are desperately seeking is a methodology.

Definition of methodology

The Treasury Enterprise Architecture Framework defines a methodology as:

"A documented approach for performing activities in a coherent, consistent,

accountable, and repeatable manner."

The Object Management Group, the organisation that has carriage of the
framework, UML, also has carriage of a standard that defines what people should
expect from a methodology. The Software & Systems Process Engineering
Meta-Model (SPEM) Specification is built to help people define methodologies.
The scope of SPEM is purposely limited to the minimal elements necessary to
define any software and systems development process, without
adding specific features for particular development domains or disciplines
(e.g., project management). The goal is to
accommodate a large range of development methods and processes of
different styles, cultural backgrounds, levels of
formalism, lifecycle models, and communities.

SPEM does this by defining two things: method content and method process.
Method content is what you do. Method content defines the artefacts that
through a flexible method process are applicable in a number of different
contexts. The method process shows you how to apply the same content for
greens field development verses what you do when you are performing
maintenance. The diagram below, directly out of the SPEM Specification, shows
you concrete examples of how the two are combined.
 Click to view large
Download full size (43 KB)

Rational Unified Process (RUP) is one of the more popular methodologies. The
SPEM specification illustrates how it displays both method content and method
process.

A good methodology is adaptable to the situation and takes you clearly through
the steps to produce quality, consistent artefacts. So if you're going to argue with
your colleagues in the break out area, make sure you're both on the same page
as to which one you're talking about. Because it's obvious you're arguing about
more than just semantics.
Managing Large Projects with Ease: 9
Pressure Reducers That Work!
May 2009

Gain invaluable insight into how to best manage the challenges inherent with large
software development projects. An industry expert reveals proven
strategies for staying on top of a wide range of tasks!

Managing large software projects can be quite difficult under the best of circumstances.
Unfortunately, individuals with limited or no experience often rely on survival tips from
more experienced co-workers and other individuals in-the-know. To help you, I compiled
nine helpful tips that will undoubtedly improve your software project management
experiences. The tips themselves originate from Washington DC-based Robert E. Bone,
an expert who has an impressive twenty-eight years of IT consulting experience that
spans analysis, applications development, requirements gathering, production support,
project management and systems administration. He highly recommends keeping these
suggestions in mind during your next software management project.

Data Load Early in Migrations

During a migration, consulting companies typically "go months and months" before they
attempt to load data. Often when the loads fail due to unforeseen mapping issues,
problems with data dictionaries, unknown data sources, and other reasons, the client is
forced to grant the consulting company additional funds while project deadlines slip.
Therefore, software project managers should seriously consider taking the following
advice:

"Front-loading the data loading in the project is a good approach," says Robert E. Bone,
who frequently rescues troubled projects. "This can result in millions of dollars in project
overrun savings, as well as helping to meet or beat deadlines."
Additionally, this project management approach eliminates the drama that is usually
associated with a production cut over - as this approach provides measurable rates of
success and improvement in data loads that occur early and throughout the life of the
project. Thus, this situation is a marked improvement over an organization having a last
minute realization that all might not be right with the data.

Document and Manage Requirements

Often clients and developers alike ignore the importance of properly managing the
requirements. For instance, the client usually just wants the project completed early and
under budget. However, in reality, disaster awaits the project manager who cannot
control the designers, developers - and the client.

It is crucial to create and maintain a traceability matrix for tying developed code back to
specific requirements. Why? Because the improper capture of requirements upfront
simply inhibits good design. Failing to properly freeze signed-off requirements results in
scope creep – i.e. situations where new functionality keeps getting added to the
requirements without approval from the client.

"I’ve yet to see anyone be able to defend out of control burn rates (funding that runs out
prematurely due to scope creep) due to either building unauthorized functionality or
repairing the damage caused by unauthorized functionality," says Bone.

Peer Review Process

Bone recommends that project managers do not “rubber stamp” peer reviews.

"I can’t stress the importance of proper peer review procedures," he says. "They often
make or break projects as they can help eliminate expensive and time-consuming rework
during late stages of a project or post-implementation nightmares."

Bone further acknowledges that he has racked up tens of thousands of dollars in overtime
- just through fixing issues that occurred because the code was not properly reviewed.

Only Work on Authorized Changes

Besides making sure that all the coding changes work correctly, it is also important to
ensure that all the coding changes are actually authorized.

"The project manager is accountable for the code that is produced, and the client will
rightly expect that the developed code can be tied directly to a requirement," he notes.
Thus, tracking changes back to requirements using a traceability matrix is beneficial.
Leverage Knowledge

Bone spent many years working for companies that compartmentalized their projects to a
point where teams were not aware of what any other teams were doing. As a result,
similar or identical work was being developed by multiple teams.

"It is certainly fine to compartmentalize – but if this is done, then set up a technical
review board that can leverage the knowledge from all of the various teams when
ramping up new projects. This is good for the consulting company and great for the
client," says Bone.

Sacrificing Quality for Completion

Throughout his career, Bone witnessed companies sacrifice quality for the sake of time in
many circumstances. In fact, he even confesses to sacrificing quality at times himself.
This type of situation often occurs as many consulting companies have rewards and
consequences attached to meeting client project deadlines.

"This situation can result in half-baked code or documents being produced and delivered
- to meet the deadline - but knowingly the results are either incomplete or just plain
poorly crafted," he says.

Bone points out that he has personally severed relationships with consulting companies
that commit these types of acts. Moreover, many years ago as a consulting project
manager, he was forced by his management company to deliver documents and/or code
that met the deadline - but was poorly created.

"The project manager is the one on the hook for both deadlines and for the quality of
deliverables," he emphasizes. "It is a failure of the project management process to allow
any situation to get to a point where incomplete or poorly completed work is delivered
simply to meet a deadline. There is no excuse for things getting to that point."

Resource Bleeding

As a project manager, Bone handles multiple concurrent projects. The result of this
situation can be quite maddening to a client, as from their perspective, the client wants it
all at the same time. Frequently, key project resources are asked to give ten to twenty
percent to one or more other projects. This situation can result in a loss of time handling,
frequent "quick questions", and "small favors."

"It is the project manager’s responsibility to be aware of resource bleeding and to protect
key resource availability for the project," he says.

The Lone Wolves

Project managers must be aware and avoid the unapproachable resource known as the
Lone Wolf. In Bone’s twenty-eight years, he has never seen the cowboy approach or the I
work alone approach work well for anyone. Bone believes that project managers can
benefit countless times by simply paying attention to the informal dialog between
engaged and cooperative team members. "That’s why it’s called a team," he says.

Allowing an individual to operate as a lone wolf is a recipe for disaster. Further, Bone
believes that this type of situation is "cancerous" to the well-being of the rest of the team.
Thus, it is really important for project managers to take the time to assess everybody’s
willingness to work together within a team.

Get Real

Project plans, timelines, charts and “pretty” presentations are all really nice, but they
often are woefully disconnected from the realities of what is actually occurring within a
project. In actuality, all of the aforementioned items are simply tools. A successful
project manager must remember that what is happening “in the trenches” is important,
not the pretty pictures.

"I worked on projects in the past where the project manager ignored team member's
expressions of issues and concerns, and where the project manager has not kept the team
informed of the project plan details," he points out.

Bone believes that taking the time to review the actual results - above and beyond simple
project reviews – is critical to the project’s success.. He cannot imagine a construction
manager taking his workers’ expressions of “everything is going great” at face value. A
construction manager comes to the site to ensure that things are being completed in
accordance with the blueprints. Obviously, the project management team will appreciate
your increased attention to detail, and only good things will result from this increased
awareness.
The Power of Effective Communication
By Kiron D. Bondale, PMP

There is a strong likelihood that if you have taken a project management training course
within the last decade you have heard some variant on the saying that “90% of a project
manager’s time is spent communicating.” As with everything else, too much of a good
thing can cause problems.

I have worked with junior project managers (as well as some seasoned ones) who focus
on over communication instead of effective communication. Their concern is that the
perceived importance of information is in the eye of the stakeholder. They are concerned
that, if the project manager does not provide "full disclosure" to stakeholders, sponsors or
team members, the project manager’s information filtering could spawn or worsen a
project issue.

This is a valid risk - a lack of open effective communication of assumptions, issues or

risks has likely caused more project failures than scope creep or limited resource
availability.

However, to swing the pendulum from limited communication to the other extreme raises
some risks. For a sponsor or stakeholder to find some data that is of value to them, they
have to wade through reams of interesting but low value (to them) information.
Additionally, drowning stakeholders in minutiae is a good way to lose their interest or
attention in your project, to say nothing about reducing credibility in the project
manager’s capabilities.

While useful for sharing project information or eliciting feedback, online communication
methods such as Twitter, Instant Messaging, and worst of all, e-mail can dramatically
aggravate this situation. While this information overload issue is dangerous for
traditional projects, it is lethal for virtual projects as it increases the probability of
stakeholder isolation or withdrawal.

So how does one determine the sweet spot for effective project communications?

1. Include a thorough stakeholder analysis as part of your project communications

planning. For key stakeholders as well as your sponsor, make sure you
understand what, when & how do they wish to be get apprised about.
 2. Leverage both push & pull methods of communicating - push information that is
time sensitive or requires action. Let other information be pulled by stakeholders
(unless they have specifically asked you to push it to them).
3. Refresh your communications plan based on feedback. Meet with stakeholders on
a periodic basis to gauge if they feel that you have an effective communication
level.
4. Be consistent in communication content & structure. This helps to reduce effort
spent by team members or stakeholders in processing information and
demonstrates predictability and professionalism.

Therefore, a governing principle of project management is "Always Be Communicating"

- perhaps this should have been re-framed as "Always be EFFECTIVELY
Communicating".

About the Author

Kiron D. Bondale, PMP, is the Manager, Client Services for Solution Q Inc. which
produces and implements Eclipse Project Portfolio Management software and
professional services. Kiron has worked for over twelve years in the project management
domain with a focus on technology and change management. He has setup and managed
Project Management Offices (PMO) and has provided PPM consulting services to clients
across multiple industries. Kiron served as a volunteer director on the Board of the
Lakeshore Chapter of the Project Management Institute (PMI) for six years and remains
an active member of PMI. Kiron has published articles on PPM and project management
in multiple industry journals and has delivered presentations within the PPM/PM domain
at multiple conferences and through regular webinars for Solution Q and the PMI
Healthcare SIG.

For more of Kiron’s views on change management, please visit his blog at
http://kbondale.wordpress.com or contact him directly at kbondale@solutionq.com .
Finding the Silver Lining:
Communicating the Progress of a
Project
By Susan Peterson

Often a project manager and his/her team only hear and read criticism about the level of
effectiveness of their work. It's always easy to criticize. There are media personalities
who make quite comfortable salaries filling the air waves with nasty remarks, sarcasm
and cynicism. Seldom, if ever, do these same people offer constructive, realistic solutions
or even provide alternatives. After listening to so much negative chatter, we can find our
own mental attitudes going sharply into a slump. The same is true for project managers
and project team members who may feel that they are constantly under attack at every
turn.

What can project managers do to promote a realistic sense of perspective about how
projects are proceeding? The first step is to focus on the goals for the project outcomes.
For example, if one of the goals was to improve the design of an existing product, what
specific improvements have been achieved? If it's early in the project and the
improvements are not yet evident, perhaps there has been demonstrated progress with
major customers in regard to innovative design strategies.

A second step is to recognize that many projects are lengthy. “Planning successes” in the
form of small, tangible deliverables at appropriate intervals can provide positive focus for
team members. This technique also aids the project manager in monitoring overall
performance in order to take corrective action before major disasters occur.

Finally, it's perfectly acceptable to let people know that progress is being made. Team
members can get buried in details and deadlines. They may need to be reminded that the
project is actually making strong progress. Those outside of the project also need to be
informed of progress in terms that they will understand. The board of directors may not
be excited that a “deliverable” has been accomplished, but they will take notice of what
the project is doing to promote stockholder confidence. The project manager can translate
the accomplishment of a deliverable into more understandable, non-project terms.

It is important to remember that there needs to be a balance between positive and

negative project “news”. We've all seen projects that had much fanfare and seemingly no
problems but that ended in disaster once the clouds of euphoria disintegrated. Much has
been written about the need to plan project parties and to always provide food and drink
at project meetings in order to bolster morale. However, most team members recognize
these tactics as superficial and meaningless if the team is not proud of the project's
progress and achievements. If there truly is little “good news” on a project, it may be time
to either substantially modify the project goals and/or the approach or terminate the
project before its planned completion. However, before taking such drastic measures the
project manager should assess the accomplishments in contrast to the problems in order
to make an informed decision.

© 2010 Susan Peterson, All Rights Reserved

Susan Peterson, M.B.A., PMP, is a consultant who manages diverse programs and
projects in both the private and public sectors for individual organizations and consortia.
She also conducts enterprise assessments of project portfolio management practices. Prior
to establishing her consulting practice Susan led major efforts for Fortune 100
organizations throughout the United States. She teaches the Project Management
Simulation capstone course as well as the Project Portfolio Management course in the
University of California, San Diego, Project Management certificate program and is a
member of the curriculum committee. She can be contacted at susanada@aol.com .
An Agile Development Success Secret: It’s
Better Caught Than Taught
By Robert Gelinas © 2009. All Rights Reserved. \\ October 2009

When it comes to the learning dynamics of an Agile development methodology in a

software development organization, getting it implemented on a sound
footing is certainly just as critical to success.

• Email
• Print
• Bookmark
• Share

The beginning is the most important part of the work.

– Plato

Like most process-oriented functions, as opposed to isolated events, getting off to a good
start can make all the difference in the world in terms of achieving overall success and
long-term continuity. Likewise, when it comes to the learning dynamics of an Agile
development methodology in a software development organization, getting it
implemented on a sound footing is certainly just as critical to success.

Parents are constantly reminded that their most important values and principles are more
powerfully and memorably transferred to their own children by means of example rather
than just words. Hence the axiom, "Values are better caught rather than taught," is most
relevant to this discussion of proper Agile implementation. "Catching" values is a
universal principle of learning which is applicable to far more than just the education of
children.

"Experience is the best teacher," we are told. Indeed, this concept is demonstrably true.
That which we learn by doing ourselves is far superior in our repertoire of skills and
knowledge than that which is merely heard or read and filed away intellectually.
Therefore, when it comes to making a fundamental change in a software development
organization's core development methodology – specifically, when migrating from a
traditional Waterfall type framework to a radically different operating approach, both in
terms of mindset and execution, the issue of exactly how you go about implementing that
change can be as important to the overall success of the change as is the decision to make
the change in the first place.

When adopting Agile, there are actually two projects we need to support – the project that
is using Agile to deliver software, and the project of transitioning to using Agile in our
teams. Unfortunately, too many companies focus on the practices of Agile, but don't
support the change needed for the transition.

– Paul Hodgetts, Agile Coach, Trainer, and CEO of Agile Logic

Iterative software development is all the rage these days, the hot buzz hyped by a myriad
of technology evangelists, the "must have" growth objective of so much of our 21st
Century software engineering. But executing a brand new development approach
productively, efficiently, and then achieving optimal results with it doesn't simply come
from reading a book or two, or attending a weekend workshop or seminar. Likewise, just
scheduling a daily Scrum meeting or releasing a new chunk of code every month from a
product backlog list is no absolute guarantee of positive results. While nimble flexibility
in your ability to execute can be a virtue, unbridled activity can also just as easily lead to
chaos and disarray.

Furthermore, just doing something for the sake of doing it isn't the answer either. That is,
the old adage you've heard many times that says, "Practice makes perfect" – is simply
wrong. No, perfect practice makes perfect. Doing something incorrectly again and again
only reinforces bad habits (and actually makes it more difficult to learn to do it right).
Being shown how to do something correctly again and again by example, and then
repeating those actions properly again and again yourself is what establishes and
reinforces good habits and makes execution seemingly effortless.

This is why many software development organizations are turning to Mentor-Driven

Implementations of Agile.

Mentor-Driven Implementations can come in the form of an onsite coach or mentor,

working with your new Scrum teams to show them how the process is properly set up and
executed first-hand, like a coach would teach and direct an athletic team. Or, it can also
come in the form of working with an entire outsourced software development
organization representing all the various development roles in the entire process from
design to release, i.e. an organization that is very experienced and fluent in Agile
development, one who will mentor a client organization with more of an "immersion
learning" type of approach.

Unlike traditional coaching, Immersion learning is more akin to learning a foreign

language by living in the foreign country of that language for an extended period of time
and being exposed to it and its associated culture on a daily basis. You learn by doing,
not just by being told. Admittedly, the one-to-many coaching model can be helpful over
time; but like our child-rearing example, it tends to be more academic in nature – like
being coached on a practice field, in contrast to physically being "in the game" and
playing.

On the other hand, the many-to-many immersion learning approach is literally learning
by doing the actual functions hand-on, by watching and emulating those who are already
quite accomplished in the pertinent disciplines, those who know how to do it well, and by
your people being able to ask real-time questions, and by receiving correction and advice
along the way. Consequently, it's a much more rapid and effective implementation
approach.

I've found that while hands-on coaching and workshops provide a much richer learning
experience than just training alone, an Agile expert working side-by-side with your teams
is even more effective in developing Agile capabilities and reducing risk when
transitioning to Agile.

– Paul Hodgetts

Of course, not every third-party software development organization out there that uses
Agile is geared to closely integrate with a non-Agile organization in a close working
mentorship model. And if they are not, then the interaction between two such
organizations can just as easily create more frustration and conflict than productivity.
However, there are some development organizations who are precisely optimized for this
very purpose, having recognized the efficiencies in the Agile development framework
and the benefits that are readily derived from helping their clients make the transition to it
and rapidly come up to speed.

I've found the single biggest factor in a successful distributed Agile implantation is
ensuring each location shares the same vision for their process model. Working with a
partner who has true Agile experience is invaluable in quickly and effectively achieving
that shared vision.

– Paul Hodgetts

However, there is still another "Gotcha" you also need to consider in the use of the
immersion learning model: Proximity.

One of the basic elements of Agile that makes it so popular these days is the concept of
close interaction between development team members—i.e. a very high degree of
functional intimacy. The phrase "everyone all in one room" can often be more literal in
practice than just figurative. So on the one hand you might feel that the immersion
learning approach with Agile sounds like a prudent means of acclimating your
organization to the new process swiftly, but on the other hand you might wonder how you
can physically have two distinct development organizations working together "in the
same room."

This is the quandary of "Distributed Agile."

Few software development organizations have adequately developed a solution to this

conundrum. The good news, however, is that some organizations have successfully
figured it out, and done so quite effectively. It can, in fact, be done, and when it is
executed well, provides the best of both worlds, i.e. allowing a client organization to
adapt to the Agile model quickly and efficiently via immersion learning, and at the same
time allows them to enjoy the economic benefits of working with an outside software
development organization to optimize overall development costs.

Now with that said, it is also true that while a Distributed Agile solution can be achieved,
it would be a gross misunderstanding to think that doing so was a trivial undertaking –
which is why so few organizations have mastered it. Successful implementation of it
requires a special emphasis on communication channels, information process flows and
communications mediums, as well as some key roles and responsibility assignments that
are unique to this particular model. But the investment in doing so is clearly worth it
when the result is increased development velocity at significantly reduced costs.

Distributed Agile development is an order of magnitude more difficult than co-located

Agile. It takes a lot of hard work to create an effective virtual team environment.
Partnering with someone who has the tools and techniques to implement distributed Agile
allows you to focus on the transition to Agile within your organization.

– Paul Hodgetts

The dynamics of not carefully thinking through an Agile implementation strategy is a lot
like a parent buying their child an expensive musical instrument and encouraging them to
learn to play it. What often happens in such situations is that the child is given a series of
initial lessons, perhaps from a private tutor, and after some period of time grows
frustrated at their lack of development and abandons it. Thus, the entire investment in the
instrument and the lessons is wasted.

But please note: what many times makes all the difference in the world with a child
learning to play an instrument and sticking with it long-term is how fast they can make
the transition from complete beginner (incompetent) to even marginally capable
(competent). Mastery may come later, if at all, but just being able to play a song and
thereby produce some positive feedback is what separates frustration from enjoyment.
From enjoyment comes a desire for more enjoyment, and therefore cultivates repetitive
behavior.

This is why more children choose to take up learning to play the guitar as opposed to the
piano. That's because an average person can be taught a few basic guitar chords and
therefore are soon able to play several simple songs, sometimes even in a single sitting.
Whereas, moving beyond basic scales and being able to play a song on a piano can take
weeks or months – of frustration. Without rapid positive feedback, only the truly
perseverant prevail.

This same human behavioral dynamic can also affect a software development team as
well. That is, if they are suddenly subjected to a new production methodology that they
aren't familiar with, one that serves more to frustrate and discourage them as opposed to
providing positive feedback and reinforcement, this will assuredly negatively affect their
output and productivity.

Conversely, if they are brought into a development environment surrounded by

productive examples that they can easily integrate with and learn by doing, thus
producing tangible results quickly and effectively, they will then seek to repeat these
encouraging and positive behaviors. That's the secret.

I've found teams are far more effective with Agile when they can follow a solid
progression of learning – start by giving them a framework of practices to safely follow,
then enhance those practices to best tune Agile for their environment, and then develop
their own ability to evolve their process. Too many organizations assume it's easy to do
the latter, without having worked through the first steps.

– Paul Hodgetts

The most effective implementation method of Agile is through immersion learning—

specifically, working in concert with a mentoring software development organization.
Just be very keenly aware that all contract software development organizations are not
alike (regardless of size). Distributed Agile implementation is a critical ingredient to the
success of the immersion learning model, and only a few organizations out there have
mastered it. It therefore behooves you to make that element a key vendor evaluation
criteria in your selection of a software development partner to help you implement Agile.

About the Author

Robert Gelinas is the President and CEO of JPE Inc. Consulting

(http://www.jpeincconsulting.com). He has spent over 20 years in the IT industry as a
senior executive and sales and marketing leader, having built many national and
international Enterprise IT sales and marketing organizations. He has both an extensive
Fortune 500 background as well as a wealth of successful Start-Up experience. He is also
a published novelist, writer, publisher (http://www.archebooks.com) and frequent public
speaker on both IT marketing and the writing and publishing industry.

About Paul Hodgetts

Paul is the founder and CEO of Agile Logic (http://www.agilelogic.com). Paul has more
than 24 years of experience in all aspects of software development, from in-the-trenches
coding to executive technical management. Paul has served as trainer, coach, mentor and
team member of agile development teams for more than eight years. His focus is on large
cross-organizational agile adoption initiatives and applying lean and agile processes to
large, multi-product, multi-team environments. Paul has served as a Program Director for
the Agile Alliance and as a member of the Extreme Programming and Java/J2EE
advisory boards at California State University Fullerton.
The Needle in the Haystack: Choosing the
Right Project Management Tool
November 2008

With a myriad of options to choose from, it’s no wonder why choosing a project
management tool has become such a daunting task. Learn how to find the
right solution for your business here!

As you well know, there are a myriad of project manager software products on the market
today. The applications, themselves, range from freeware, like Comindwork and
Openproj, to multi-faceted programs with service contracts that can cost in the tens of
thousands of dollars. Further, the software is made by familiar name brands – such as
Microsoft Project to software that is created by more obscure startup companies.

All of these choices can, not surprisingly, make IT executives apprehensive about
choosing the right software programs for their businesses.

“If I were trying to buy some software I would not even know where to start – since there
are so many choices,” said Dave Farthing, a Chartered Engineer, British Computer
Society Member and professor who lectures on software development project
management, among other disciplines, at the University of Glamorgan in the U.K.

To alleviate some of the confusion, Farthing compiled a list of more than four dozen
automated products on his university-hosted website.

To offer further explanation, each of the items on the website comes with a short
description of its capabilities and a link to the maker’s website. However, despite this
helpful list, Farthing believes that companies should always properly assess their goals
and existing infrastructure – before implementing a new program.
IT Executives Should Examine Company Culture

Farthing also believes that the prevailing zeitgeist within an organization is key to
determining what kind of project management tools the company should use.

“Some organizations, because of traditions and so on, need to have, or there are
accustomed to having very tight project control and very strict procedures,” he said.
“Sometimes that is an external constraint”.

He identifies the public sector as having, in general, a greater need for accountability than
private companies. Consequently, software that provides detailed project tracking of
changes and effective cost summarizing is of particular use to those groups.

The public/private sector split is but one nuance in a wide array of determining factors.
Farthing further notes several key functions of automated software project management
tools – each with a varying degree of relevance based on the type of organization that
would be using these project tools. These key functions are as follows:

• Software that can help managers perfrom accurate project cost estimation,
evaluate time, and other factors
• Tools that deal with document management and work group collaboration –
especially helpful for large organizations with far-flung departments
• Software that can help with the issue of tracking and calculating costs – especially
helpful for international businesses that deal with customs and tariffs
• Configuration management tools and devices that help to keep track of
conversions
• Change control and defect tracking software

Of course, IT leaders should identify the key project management processes within
individual companies and narrow the market to include only those products that service
these key processes.

Taking these project management steps can cut costs as well, since this method can
eliminate the buying of redundant or useless tools.

Varying Claims about Automated Products Cause Confusion

While narrowing a company’s market focus is helpful, it can still be difficult to identify
just what a specific product is capable of doing for a company.

After all, the marketing copy on product websites often raises more questions than
answers. Here are some marketing pitch examples from various companies:
 • OroLogic boasts that its OroTimesheet 5 “is the best timesheet software on the
market!” Further, the website claims that this software is “incontestably the best
solution to track your projects simply, efficiently and intelligently.”
• Method 123, in advertising its Project Management Templates, reports that its
software is “incredibly detailed,” “easy to read and use for projects” and “suitable
for all project types and sizes.”
• InterPlan Systems touts its eTaskMaker as “fast and easy to learn.”
• Project Perfect declares on its website that its product creates “really useful
Project Management Software”. Further, the company says that its Project
Administrator tool is “invaluable for issue tracking”
• TrackStudio begins its online pitch with the statement that “TrackStudio is
different. TrackStudio is better.”

All of these claims may be 100 percent true, 100 percent false, or a combination of both
accurate and inaccurate claims. In any case, IT managers will find it difficult to verify
these points unless they can actually use these products – or talk to someone who has
actually used these applications.

At this point then, it makes complete sense for IT managers to seek out independent
research that reviews software applications.

Farthing recommends that companies look at various magazines and journals. In

particular, he believes that “Project Manager Today,” a British publication that twice
annually categorizes and highlights software project management tools, is a good one to
read.

“This magazine is a good starting point," he said.

Ultimately, companies should try to find objective information. However, finding

objective information is challenging due to corporate public relations on one side, and
unsubstantiated claims posted to online forums on the other side.

“You need to be careful about taking too much heed of one person’s scare-mongering,”
Farthing added.

Yet a source such as “Project Manager Today” is just a single voice among many
potential voices. In other words then, varied and detailed the research yields better
results.

“If many people are having a bad experience with a particular type of software, then you
are getting a clearer picture,” Farthing said.

Software Project Management Tools Require a Vigilant Eye

As IT executives survey the experiences of other product users, they must keep as
vigilant an eye on what goes on internally.
Automated tools are not, as the term may imply, devices that one can just “set and
forget.” IT companies must evaluate their cost-effectiveness – just like they scrutinize
every other facet of the operation.

Companies that deal in software may have the built in advantage of inherent product
knowledge and a healthy level of skepticism, Farthing believes.

“Software engineers know that things can go wrong, and anybody who has been in the
industry long enough realizes that a very simple misunderstanding or simple error can
make a huge difference,” he said.

Still, the nature of these devices, especially the more wide-reaching and expensive ones,
can implant a great degree of reluctance to change course in a company.

That said, the purchase price and licensing costs are not the only expenses involved with
the use of an automated management tool. There is often costly training that must take
place. Further, costly manpower must spend a great deal of time on tasks like data input
and testing during the product implementation stage.

Additionally, if a company has been using a particular product for a long duration, there
is the question of what to do with all of the archived data.

“If all of your records are in an old system that you cannot use anymore, then you are left
without that useful information,” Farthing said.

Unless there is a truly compelling reason for change, IT companies are often best advised
to continue their use of the automated software project management system they
currently have – simply because of the high price a change of software would cost a
company.

“It does really become quite expensive in the end,” Farthing added.

However, the industry could perhaps benefit from the greater standardization of data
storage that could provide the flexibility necessary for companies to readily switch to the
most effective project management systems.

“If your data was stored in a standard way, it would be relatively easy to move it from
one package to another,” Farthing said. “Also you could use tools on that data to query
new bits of information that perhaps you were not able to access before.”

Clear Vision Required From Management When Selecting and Evaluating

Tools

Given the cost of automated software project management tool implementation, there is
an emphasis on getting the software choice right the first time around.
IT executives must understand the following about their company’s software project
management platform:

• Which software project management platform areas could be aided by automation

• Which products are likely to work and which products are not likely to work
• How these products perform once they are a part of the project process.

To conclude, while there is a need for informed leadership during the selection process,
this requirement does not disappear once software automation is implemented.

After all, as Farthing said: ”software needs to support management – but not drive the
project”.
Project Manager vs. Project Leader
By Andy Jordan \\ September 2009

What’s more valuable in the long run? A project manager or a project leader?
Project managers do fine, but project leaders take it one big step further.

I'm assuming that everyone understands what project management is. Most people
reading this will have studied the PMBoK, learned various methodologies, read the
books, etc. You understand that project management is the application of skills, tools,
techniques and knowledge to project activities in order to complete the project objectives.
I'm paraphrasing the PMBoK, but everyone's definition is similar.

Well you are all wrong!

Okay, that was a little melodramatic, but I can't accept that definition – project
management to me is more than that. PMs have a responsibility to manage their teams –
even in a matrix organization – and that means being a leader. Stop thinking about a
project manager, and start considering the concept of a project leader. Let me explain
what I mean.

Project Leadership vs. Project Management

Project managers are automatically in some form of a leadership position – they are
controlling the project activities for their initiatives. In many cases they may not control
the resources, but this doesn't stop them from being leaders.

Don't confuse leadership with authority – they aren't the same. I expect an effective
leader to be able to inspire and motivate their teams, to develop their resources to be
more effective contributors, to understand how their work fits in to the bigger picture and
to be able to make the tough decisions when necessary. Does anyone think that doesn't
also sound like an effective project manager?
It is short-sighted to see a PM simply as the person responsible for managing a set of
tasks – project work is completed by people, and they need more than task-based
management. The rest of this article is my attempt to outline what I believe a good
project leader should be able to do.

The Easy Stuff: Motivating the Team

Being a project manager is often an emotional rollercoaster – the highs of a key milestone
hit and the lows of an issue that just cost you two weeks – but the situation is exactly the
same for project team members, often without the benefit of an understanding of the
project-wide picture. The PM has to be able to manage people's emotions, to bring people
up when they are down, to bring teams together when finger pointing is coming to the
surface, and above all to keep them focused on the goals of the project.

This is not always easy; as PMs we have to understand the individuals that make up our
team – what are their personalities, what makes them tick, which ones respond best to a
pat on the back and which ones respond best to a kick up the baseline. There is no simple
strategy that you can apply, you simply have to be able to understand your people and
demonstrate true leadership – be someone that the team looks up to, someone they don't
want to disappoint.

You can't do that with a gantt chart, or with the prospect of an upset customer. You have
to make it personal; make a connection with each person and make them care about more
than just the paycheck. I have done it with a sense of pride in a job well done, with the
prospect of having to face the personal disappointment of failure... it doesn't matter as
long as it connects with the team member. Additionally, say thank you – not necessarily
with a big bonus, sometimes literally with a “thank you”.

When I have provided tangible rewards, it is again something personal – the promise of
an extra day off on a family birthday, flowers sent home to a wife whose husband was
working a weekend, even once a gallon of chocolate milk.

The Hard Stuff: Saying No

All of the above is all well and good, and I suspect that many PMs do it automatically...
that's why I called it the easy stuff. If a PM is going to be a true leader, they have to be
able to do more than that. One of the hardest but most important things that a PM has to
do is to say no. Not every project can be completed on time, on budget and on scope.
There are times when the right approach is not to try and motivate the team for one more
big effort, for one more all-nighter, for just one additional weekend in the office. There
are times when the right approach is to push back and not let the team be pushed through
additional stress with no prospect of a positive outcome.

The difficulty is recognizing when that moment has come, and that's something no one
can tell you. It will vary from company to company, and project to project. All I can tell
you is the question that I think you need to answer to make the decision: Is the cost of the
effort greater than the benefit from the outcome? Is the pain worse than the gain? This is
not the same as “Can the project be saved?” I don't want to deliver a project on time,
scope and budget only to have two-thirds of the project team resign because of the way
that we treated them, and I don't think many organizations would want that either.

There are a large number of variables going into that decision – the importance of the
project, the likelihood of success, the specific people involved, etc, and there is no easy
answer to the question, but it is a true test of leadership. Of course you need to be
professional and constructive. The answer is never simply “no”, it's always working with
stakeholders to find better approaches, look at other recovery options, etc., but the bottom
line is that it is moments like this when your leadership ability will truly be tested.

The Forgotten Stuff: Staff Development

There is one other vital opportunity for PMs to demonstrate leadership, and that is in the
development of their project teams. To my mind, every project should have an additional
goal – to deliver increased organizational project capability as a result of completing the
project. The project team (and the individuals within it) is more capable in their work on
projects as a result of their involvement on the project.

This is no different from the staff development responsibility that a line manager has, and
I would strongly urge PMs to work with line managers in building development plans,
training, etc. However, PMs are in a unique position to identify needs, aspirations, etc.,
because they often aren't line managers, and team members may find it easier to share
their plans more freely than they would with their manager.

Too often, organizations miss out on the opportunity to use projects as a training ground
to develop new skills and build experience in people. The focus is always on the shortest
possible timeline, not on the largest possible benefit, effectively mortgaging future
capability to save a week or so now.

Conclusions

Projects are businesses in microcosm – pretty much every function that is needed to make
a business successful is needed to make a project successful. You'll never hear a CEO say
that their company doesn't need leaders or leadership because they have management,
and yet that seems to be the norm for many projects.

As PMs, you have a responsibility to provide leadership to your teams as well as all of
the skills required of project management. This takes effort, but the rewards are immense
– for the teams, the company and the project manager... or should that be project leader?

About the Author

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada based

management consulting firm with a comprehensive project management practice. Andy
always appreciates feedback and discussion on the issues raised in his articles, and can be
reached at andy.jordan@roffensian.com . Additionally, Andy is involved in the
development of a new Canadian professional project management body – the Project
Management Association of Canada. Learn more about them at http://www.pmac-
ampc.ca.

Copyright © 1999-2009 gantthead.com, Inc. Reproduced by permission of

gantthead.com, Inc.