Pages

jeudi 28 mars 2013

Now, let’s say you have done a good job
defining and planning the project. You’re home free, right? Not exactly. It is very common that once the project starts, the
sponsor
ends up asking for more (or different) work than what was originally agreed to.
This is the time you must invoke scope change management. If you don’t, you will
end up trying to complete more work than what was originally agreed to and
budgeted for. In other words, you are heading down the road to trouble.

Five Project
Management Mistakes

Mistake #2: Poor scope management practices

Managing scope is one of the most critical aspects of
managing a project.
However, if you have not done a good job of defining scope, managing scope will
be almost impossible. The purpose of defining scope is to clearly describe and gain agreement on the
logical boundaries and deliverables of your project. The business requirements
are gathered to provide more detail on the characteristics of the deliverables.

Defining scope means that you have defined the
project boundaries and deliverables, and the product requirements. These should
all be approved by your sponsor.

The project manager and project team must
realize that there is nothing wrong with changing scope - as long as the change
is managed. If you cannot accommodate change, the final
solution may be less valuable than it should be, or it may, in fact, be
unusable.

Every project should have a
process in place to manage change effectively. The process should include
identifying the change, determining the business value of the change,
determining the impact on the project and then taking the resulting information
to the project sponsor for their evaluation. The sponsor can determine if the
change should be included. If it is included, then the sponsor should also
understand the impact on the project, and allocate the additional budget and
time needed to include the change.

The most common problems with scope change
management are:

Not
having the baseline scope approved, which makes it difficult
to apply scope change management.

Not
managing small scope changes leaving yourself open to "scope
creep".

Not
documenting all changes - even small ones.

Having the project manager
make scope change decisions instead of the sponsor (or
designee).

If you find that your project is starting to
trend over its budget and schedule, try to find the cause. In many cases you
will find that you are simply taking on more work than you originally agreed to.
If you do not
have a good scope change process in place, it is never too late to start.

lundi 25 mars 2013

Takeaway: Many
of the issues plaguing IT departments can be mitigated or sidestepped
altogether. Here are some ways to deal with several common pitfalls.

IT faces challenges on a daily basis. But most
experienced IT’ers have learned to avoid the worst sand traps so they
can prevent time and energy drains. What are today’s biggest IT sand
traps — and what best practices can you use to circumvent them?

1: Uncooperative users

Uncooperative users are still out there, as they have been through
the years. Most don’t cooperate out of fear of a new application — or
because of a comfort level with a present application that they don’t
want to give up. It is important for IT to remember that when it changes
an application, it also changes a person’s daily workflow. This can be
disconcerting, even for younger users. The key is to engage users in
application dialogues at the very beginning. Involve them in early app
design and prototyping so they already know and buy into how the app is
going to work before it is ever plugged into production.

2: Unhelpful users

Unhelpful users are trickier to work with because they frequently
come in the guise of “helpful” individuals who cross a threshold when
they become too helpful. They offer reams of tweak suggestions
for apps and never want to accept an app as being complete for a given
release. Enhancement creep of this nature introduces risk into IT
project deadlines. The best way to deal with it is to establish firm
cutoffs for app development and enhancement cycles that everyone agrees
to.

3: Lack of tool integration

Everyone talks about cloud, mobile computing, and the blurring of
lines between computing platforms. But vendors of infrastructure
software don’t necessarily make managing across a diverse environment
easier. Each vendor wants you to use its own toolset for management, and
it isn’t always clear which tools are subordinate to other software
infrastructure management tools. Consequently, it becomes difficult to
fit everything into an “uber” infrastructure solution where you really
can see everything through a single pane of glass. The best thing for IT
to do is to require prospective tool vendors to show what application
programming interfaces (APIs) they have that work with other management
software. The APIs can be tested with other software in a proof of
concept (POC) before buying. Finally, avoid the use of homegrown tools
that don’t readily interface with anything on the market.

4: Platform loyalty

IT’s strength is its technical know-how. This know-how is accumulated
over the years and becomes a career calling card for most IT
professionals. Unsurprisingly, the sledding can get rough when someone
who has worked on say, UNIX, for 20 or 30 years, is told to move to a
Linux environment.
One way to ease the transition (if it is necessary) is to introduce
these individuals to the new platform and provide the training and
support they need for the crossover. If they’re adamantly opposed to the
change, there might be an opportunity for them to move into a
maintenance role for systems that will continue to run on the old
platform. If you can’t provide that role, as a last resort you might
have to encourage them to seek employment elsewhere — in a shop that
continues to use the platform they want to work on. In all cases, it is
best to address these platform loyalty cases immediately and upfront,
before resentment (and even lack of cooperation in projects) begins to
set in.

5: Poor project management

Despite new project management techniques and tools, project
management remains a weak area in IT. There are several reasons for it: a
failure to cross-communicate across the project; the failure of project
managers to “walk around” and really check out first-hand the status of
work (besides just seeing the updates on a project tracking chart); and
a breakdown of communications between the IT and the end user sides of
the project team.
The best way to ensure great results in projects is to make projects
smaller (and therefore more manageable), to encourage (and enforce) open
communications, and to use collaborative project management tools that
are now available in the market. It is equally important to perform post
mortems of all project work — to learn what went right and what could
have been done better on each project — and to take that knowledge into
future projects.

6: Lack of documentation

Documentation isn’t stressed in IT, which makes it a weak link in
most IT work. No wonder most IT departments report that upward of 50
percent of their time is consumed in app maintenance. Less time would be
spent in maintenance if documentation of what the original app was
doing (along with history of maintenance already performed) had been
done. Two ways to combat this are the adoption of new app development
software that automatically documents work and a build-in of project
time for app documentation and QA of the doc.

7: Poor data quality

The best technology in the world isn’t going to change duplicate
customer records with misspelled addresses or incomplete phone numbers.
For data already on record, data deduplication can be used to ferret out
duplicate records before they are stored or archived to disk. For new
data, better field edits in applications can improve the quality of data
that is being entered into data repositories.

8: Jargon

IT (like other technical disciplines) can become so comfortable using
acronyms and jargon that it doesn’t realize that it is using these
terms with business users who might not understand them. This can
generate communications breakdowns or even intimidation in
relationships. IT can avoid this by stressing (and if necessary,
training) IT staffers who work with end users to avoid these specialized
terms and to stick with plain English.

9: Unrealistic deadlines

The pace of business is relentless and quick. As usual, IT gets
pushed into accepting project deadlines that are too aggressive for the
work that needs to be done. When this happens, IT delivers incomplete
projects that are missing key pieces that subsequent enhancement cycles
must handle. This is okay if the business is in total agreement with the
approach. (In fact, it has worked very well in some areas, such as
marketing.) However, if there is a governance/security issue, or if the
app is required to be both complete and thoroughly tested, it is IT’s
responsibility to tell business management what the effort will take,
how long it will take, and what the risks are if the effort is not
undertaken.

10: Lack of people skills

IT continues to come up short in soft skill areas.
CIOs should recognize this by budgeting for and providing people skills
training to key IT contributors — and they should up the ante by
soliciting feedback from end users on the quality of IT interpersonal
communications.

Other sand traps?

What issues have been a problem for you during your IT career? Share
your experiences and advice with other TechRepublic members.

Did you know that there are more possible moves
in a game of chess then there are atoms in the entire universe and
seconds that have elapsed since the big bang? In fact, chess can be a
virtually endless game. If that’s the case then how do chess masters
emerge? What’s the point of trying to study something if the moves are
endless? Any good chess player will tell you that one of the keys to
success is the ability to recognize patterns and situations to help you
identify what the best next move is.
When looking at collaboration and the future of work, the same logic
applies. Every company is unique and no two collaboration initiatives
are the same. However, after working with, speaking with and
researching hundreds of companies (such as Wells Fargo, Unisys, Lowe’s,
IBM, EA, The U.S. Government, TELUS, Intuit, Shell, and many others) my
team at Chess Media Group
and I have identified twelve collaboration patterns or “principles” that
the successful organizations follow. Below you will find a visual
highlighting these principles followed by a more in-depth description of
each one.1. Individual benefit is just as important as the overall corporate benefit (if not more important)
Don’t focus on the overall corporate value and benefit when
communicating collaboration to employees. Employees care about how this
will impact them on an individual basis. How will this make their jobs
and lives easier?2. Strategy before technology
Before rushing to pick that shiny new collaboration platform focus on
developing a strategy which will help you understand the “why” before
the “how.” This is crucial for the success of any collaboration
initiative. You don’t want to be in a position where you have deployed a
technology without understanding why. This can become a very costly
mistake later.3. Listen to the voice of the employee
We are always so adamant about listening to the voice of the
customer, what about the voice of the employee? When going down the
collaboration road within your enterprise it’s important to make
employees a part of the decision making process from step one. Listen
to their ideas, their needs, and their suggestions and integrate their
feedback in your technology and strategy.4. Learn to get out of the way
This is something Andrew McAfee (author of Enterprise 2.0 and
co-author of Race Against the Machine) talks about quite frequently.
Learn to empower and support your employees and then get out of their
way. By trying to enforce and police everything you stifle
collaboration within your organization. Some best practices and
guidelines are fine to have but let your employees do what they need to
do. Managers need to learn to follow from the front.5. Lead by example
If leaders at your organization don’t use and support collaborative
tools and strategies then why should the employees? Leaders are very
powerful instruments to facilitate change and encourage desired
behaviors. They must be visibly on board and this goes beyond just
funding.6. Integrate into the flow of work
Collaboration should never be seen as an additional task or
requirement for employees. Instead collaboration should fit naturally
into their flow of work. For example instead of having employees use
multiple usernames, passwords, and log-in sites; create a “front-door”
to the enterprise accessed through your collaboration platform.7. Create a supportive environment
If your organization focuses on rewarding employees for individual
performance as the main driver of success then it will become quite hard
to encourage employees to share and communicate with each other. Why
would they want to? We this quite often in financial services firms who
promote employees to managerial roles such as VPs (and higher) simply
because they brought in a lot of money. There is nothing wrong with
rewarding employees for great performance but it’s also crucial to
reward and recognize teamwork and collaboration. For example
organizations can make a percentage of an employee’s bonus tied to how
well they collaborate with their co-workers (some large enterprises are
starting to experiment with this). A supportive environment also means
having training and education resources available for employees as well
as evangelists within the organization.8. Measure what matters
There are a lot of things that an organization can measure but that
doesn’t mean that all of these things should be measured. Focus on the
metrics that matter to your organization and the ones that are tied back
to a business case. Some organizations focus on “busy” metrics such as
comments submitted or groups created. Others focus on metrics such as
engagement (defined as how connected and passionate an employee feels
about the company and the work they do).9. Persistence
I believe that collaborative initiatives shouldn’t be pilots they
should be corporate initiatives. These efforts can certainly take time
but if the organization makes the decision that collaboration is the
direction they want to go down then that’s it. No giving up and no
turning back. Moving forward, organizations cannot succeed without
connecting their employees and their information. Making collaboration
work isn’t an option it’s THE option.10. Adapt and evolve
It’s important to remember that collaboration is perpetual. It’s a
never ending evolution as new tools and strategies for the workplace
continue to emerge. This means that it’s important for your
organization to be able to adapt and evolve as things change. Keep a
pulse on what’s going on in the industry and inside of your
organization. This will allow you to innovate and anticipate.11. Employee collaboration also benefits the customer
While customer collaboration and employee collaboration do solve very
different and unique problems, employee collaboration has tremendous
value to your customers. Employees are able to provide a better
experience and superior support by being able to tap into internal
experts, information, and resources which can be used to help
customers. Consider a customer that is working with a support
representative who unfortunately does not know how to solve the
customer’s problem. The employee however has access to the entire
organization to find the right information and share it with the
customer.12. Collaboration can make the world a better place
Perhaps the most important principle of collaboration is that it can
make the world a better place. Sure, collaboration can make our
employee more productive and benefit our customers. But collaboration
also allows employees to feel more connected to their jobs and
co-workers, reduces stress at the workplace, makes their jobs easier,
allows for more work freedom, and in general makes them happier people.
This means less stress at home, less arguments with spouses, and more
time to spend with loved ones. Collaboration not only positively
impacts the lives of employees at work but also at home.

The
following series of five emails describes the five most common project
management mistakes.

Have you ever attended an end-of-project meeting
on a project that had major problems? If you have, chances are that one of the
major themes you will hear is that we should have spent more time
planning.

Five Project
Management Mistakes

#1: Inadequate Planning

I have heard project managers say that the time
they spend planning could be better spent actually "doing the work". This is not
right. Before the project work begins, the project manager must make sure that the work
is properly understood and agreed to by the project sponsor and key
stakeholders. The larger the project, the more
important it is that this information be defined formally and explicitly. When
you think about it, many project problems can be traced to problems in planning.
These include

Poor estimates based on not
understanding the totality of the work.

Lack of scope change
management because scope was not properly defined to begin
with.

Issues occurring because of
poor risk management.

Missing work because the
schedule is not thought out.

Not understanding all the
stakeholders involved.

It
should not be surprising, then, that the best way to avoid this problem is to do
a good job of planning the project up-front. There are four main components to
the planning process.

Defining the work. You need to
understand the nature of the project including objectives, scope,
assumptions, risks, budget, timeline, organization and overall approach.

Understanding the schedule. You should create a
project schedule before the project starts. This is needed to help you determine
how to complete the work, and to estimate
the total project effort and duration.

Estimating costs. You and the sponsor need
a good estimate of costs before the project gets going.

Agree on project management
processes. This will include how the
project manager will manage scope, issues, risks, communication, schedule, etc.

People ask me how much time it takes to complete
the project planning. The answer is "sufficient". You need to spend the time to
define the work, create a schedule, estimate the costs and set up the project
management processes. If your project is small, this should not take much time.
If your project is large the planning may take a log time. In other words,
planning is scalable based on the size of the project.

Spending time on good planning ends up taking much
less time and effort than having to correct the problems while the project is
underway. We all know this to be the case. We just need to practice this on our
projects.

Your IT project will soon be in trouble if you
fail to establish configuration management (CM) as early as possible
during the systems/software development life cycle (SDLC). This is true
regardless of whether you use a traditional software development
methodology/process such as “Waterfall” or an Agile, iterative
methodology. Ideally, you should start thinking about CM before or
during the proposal activity. An effective configuration control library
provides control over documentation, source code, etc. and streamlines
the build/release process. Finally, you must also ensure the use of best
practices for program/project management, development, quality
assurance (QA), and so on.

Why is CM so essential?

CM is a process for establishing and maintaining consistency of a
product’s performance, functional and physical attributes with its
requirements, and design and operational information throughout its
life. (MIL-HDBK-61A, Military Handbook: Configuration Management Guidance, Department of Defense. 07-February-2001 and ANSI/EIA-649B, National Consensus Standard for Configuration Management, TechAmerica. 01-April-2011.)
Effective CM is essential to ensure customer/user satisfaction and
develop a quality product. Without CM, it is almost impossible to
control the documentation, source code, and other data that describe
your system and are used throughout the SDLC.

The 10 steps to ensure successful CM

Create your CM plan during the conceptual demonstration and
validation phase, which the Rational Unified Process (RUP) refers to as
Inception and Elaboration.
1. At contract award, identify the configuration items (CIs) based on the following criteria:

Note: CIs are also called Computer Software
Configuration Items (CSCIs) for software systems development. The
configuration identification process was originally defined in
MIL-STD-973, 483, and DOD-STD-480A.
2. Determine the appropriate development methodology for the system or product (if not yet decided).
3. Specify the required documentation for each product (CI/CSCI)
based on the contract requirements, standards, and specifications. Note:
A waterfall project may have extensive specification documents. For
Agile, brief but well-defined user stories with limited text and
diagrams and tasks for each iteration are often preferred.
4. Set up the configuration control library. It does the following:

Provides control of master files and documentation (on-line and
offline), such as specifications, related documentation, computer
programs, software, databases, etc.

Supports the build and release processes and activities.

5. Set up a change management process that includes configuration
control and a secondary process to expedite critical or time-sensitive
changes.
6. Issue numbers and identifiers to each product (CI/CSCI), its components, and related documentation. Important: It really helps to establish consistent naming and labeling conventions for requirement and design documentation, interfaces, code listings, and so on.
7. Determine and prioritize the planned component or functional
releases (deliverables), based on the requirements and the architecture.
8. Establish the configuration baselines. Configuration baselines are
points in time for management, control, and release purposes.
9. Set up QA, validation and verification (V&V), and/or test validation processes that complement your CM method.
10. Throughout your program or project, do the following:

At TenStep, we define
three major categories of communication within a Communications Plan –
mandatory, informational and marketing. If your project is controversial
or if it requires culture change to be successful, you should focus on marketing communications.

Branding is a more
sophisticated form of marketing communication. The purpose of branding a
project is to associate an emotion or a feeling with your project. This
is exactly what marketing people try to do when they brand a product.
For instance, The Coca-Cola Company hopes that you feel good about its
products and that you will choose its products from a crowded store
shelf because you like the image and emotion associated with it. Maybe
it works.

The purpose of branding
a project is to associate a positive image and emotion with your work.
This is not something most projects need to be concerned about. However,
ask yourself some questions regarding the impact your project will have
on the organization.

Does it impact a large number of people or maybe the entire company?

Will it require a culture change or a change in the way people do their job?

Will your project
make people nervous or afraid? For instance, will it result in
efficiencies so that less people are required to do the same function?

These are the types of projects that would be candidates for branding.

All large projects get
branded. If you don’t do anything, this branding is generally negative.
It is just the nature of people that they seem to think that change is
bad. Positive branding communication helps you proactively build the
image you want to portray rather than getting stuck with one.

When considering a
branding strategy, ask whether it is important for people to have a
positive feeling about your project. For example, when people hear of
your project, do you want them to think of the benefits your project is
bringing or do you want them to think about how bad the project is?
Should they think of the company responding to competitive challenges or
should they be wondering if the project will cost them their job? Do
you want them to have positive thoughts or negative ones?

There are activities
that a project can perform to help with the branding campaign. Examples
of activities include establishing a positive project name,
distributing banded materials, publicizing project successes, etc.

Why the fuss?

You might be wondering
why this all matters. Does this sound like just a bunch of fluff and
unnecessary work? It is not. It matters because it is much more
difficult for your project to be successful if the people that have to
change are negative. It is much easier for you if they are positive
about the change - or at least neutral. That is where the value-add
comes in.

mardi 19 mars 2013

If you'd like to know what your team are
working on and how long tasks are taking, then ask your team to fill in
basic timesheets.

Unfortunately, if you mention "timesheets" to team members they will often groan! So learn these 5 steps on...

How to Encourage Your Team to do Timesheets

Make it easy for your team to record their time with these 5 simple steps.

Step 1: Explain why you are collecting data
People are more likely to complete their timesheets if they know what
you are doing with the information. Explain how it helps you manage the
project more effectively. You can tell them that it provides really
useful information to validate the estimates and it ensures that
everyone is working on the right things at the right times. You can
adapt the project schedule depending on how quickly tasks are being
done.

Step 2: Make it easy
One of the reasons why people don't complete timesheets is because
they are difficult to fill in. They don't have to be. Choose an online
project management tool that allows everyone on the team to complete
their timesheet information with a few clicks. Look for one that has a
'copy previous week' button like the one in this Time Tracking Software to save even more time.

Step 3: Link the data to the project plan
Ideally your timesheet data should link automatically to the project
plan so team members don't have to complete two sets of information.
They will feel as if the software is actually helping them to do their
job instead of asking them to fill in lots of forms for seemingly no
purpose.

Step 4: Share the reports
Time tracking reports allow you to see if your project is running on
time or if you are behind schedule. These can be really useful tools to
help you manage the project successfully. You can also see how much time
has been spent on the project to date. Showing the reports to your team
members can help reinforce the message that their timesheet data is
very valuable and that it is worth completing the timesheets.

Review the reports before you share
them with the team as you don't want confidential information to be
available publicly. That shouldn't be a problem for most projects but it
is worth checking before you send the information to everyone.

Step 5: Review your estimates
Finally, use your timesheet information to review your estimates on
the project. If a task is taking longer than expected, this is a great
time to change your project schedule as appropriate. Use the historical
data from timesheets to better predict the future. After all, if a task
took longer than expected, chances are that your estimate was a bit
optimistic and you'll need to review it for next time.

mercredi 13 mars 2013

Just as a project should have a
formal end-of-project meeting to signify that it is complete, you should
also hold a formal kickoff meeting to start a project.

The purpose of the kickoff meeting is to formally
notify all stakeholders that the project has begun and make sure
everyone has a common understanding of the project and his role.
Like all formal meetings, there should be an agenda.
There are
a number of specific things you want to cover at this meeting:

Introduce the people at the meeting.

Recap the information in the Project Charter, including
the purpose of the project, scope, major deliverables, risks, assumptions,
etc.

Discuss the important roles and responsibilities of the project
team, clients and stakeholders. If there is confusion about
the role of any person or organization, it should be discussed and
clarified now.

Go over the general approach and timeline of the project. This
gives people a sense for how the project will unfold. In particular, you
will want to ensure that people understand what they need to be doing in
the short-term to support the project.

Answer any outstanding questions. The purpose of the
discussion is not to rehash the purpose of the project, but to allow
people to voice specific questions or concerns they have as the project
begins.

Confirm that the project is now underway. If the project has not
started yet, it should now be ready to start immediately.

In
general, the project team, sponsor and
major
stakeholders should be in attendance. If this results in too many
people for
comfort, you can consider having only the major players
attend. You
can then meet with others in subsequent mini-kickoff
meetings or
you can send the relevant meeting information to the people
who could
not attend.

Although most
kickoff meetings can be conducted in an hour or two, others might
require a day or two. The longer kickoff meetings are especially
important if the project is very complex or controversial.

It
is said you never have a second chance
to make a
good first impression. This is true with the kickoff meeting.
You are
using the meeting to help set expectations for the project. If
the
meeting is unorganized, chaotic or a waste of time, the participants
will
probably carry those perceptions into the project as well. The
project
manager needs to make sure that he has prepared well for this
meeting
and that it goes smoothly.

Back in the 60', Motown's "I Heard it
Through the Grapevine" was a huge hit, made famous by Marvin Gaye's
recording. Even though he himself is no longer with us, the grapevine he
sang about is alive and well, as it's a timeless metaphor for the way
news travels.

In a project environment, the circulation of unofficial information and rumors is enough to make heads spin. We set up official communication plans
that detail who knows what and when, but struggle with managing the
unofficial information. The following are tips to stop the confusion and
manage the grapevine effectively:

Tip 1 - Become Part of the Grapevine
People love talking about what goes on within their work
environment. The grapevine truly does exist in all companies. Assume
the projects you manage are one part of that conversation, insert
yourself into it and ask people what they are hearing about your
projects. Is there any news from above? Are resources happy? Then, be
sure to add your own facts into the mix. A little bit of accurate
information never hurt anyone.

Tip 2 - Combat Negative Messages with Facts
Negative communication sometimes gets spun into a mile-long email
thread. Inaccurate information and intensity of emotion continue to
escalate the longer the email thread grows. The best antidote to
negative communication is to get the facts out there as quickly as
possible. Compose a thoughtful and precise "Reply All" with a handful of
relevant facts to get everyone in sync. Then, kill the thread and take
it offline.

Tip 3 - Stop the Bad Press
Most talk on the grapevine is harmless, primarily serving as an
interesting diversion during a long day at work. People don't really pay
that much attention to it. However, innocuous gossip can turn into
hurtful and malicious slander. You need to track down the source of that
information immediately and make it stop. Find out why someone feels
compelled to put forth such negative propaganda about your project and
deal with it face-to-face.

Tip 4 - Fill the Vacuum
You may have projects that aren't impacted by negative
communication. However, you are left with a vacuum of communication.
It's up to you to fill this void with positive and factual information
about your project. Send out pertinent emails, give appropriate updates
at company meetings, and have one-off conversations. That way, people
will really have something to talk about when your project gets tangled
up in the grapevine.

The grapevine has been around since
the time the 3rd person walked on this Earth. There's nothing you can do
to stop it from happening, so include it as part of your unofficial
communication plan. You'll notice a big difference with the buzz on your
projects.

mardi 12 mars 2013

Back in the 60', Motown's "I Heard it
Through the Grapevine" was a huge hit, made famous by Marvin Gaye's
recording. Even though he himself is no longer with us, the grapevine he
sang about is alive and well, as it's a timeless metaphor for the way
news travels.

In a project environment, the circulation of unofficial information and rumors is enough to make heads spin. We set up official communication plans
that detail who knows what and when, but struggle with managing the
unofficial information. The following are tips to stop the confusion and
manage the grapevine effectively:

Tip 1 - Become Part of the Grapevine
People love talking about what goes on within their work
environment. The grapevine truly does exist in all companies. Assume
the projects you manage are one part of that conversation, insert
yourself into it and ask people what they are hearing about your
projects. Is there any news from above? Are resources happy? Then, be
sure to add your own facts into the mix. A little bit of accurate
information never hurt anyone.

Tip 2 - Combat Negative Messages with Facts
Negative communication sometimes gets spun into a mile-long email
thread. Inaccurate information and intensity of emotion continue to
escalate the longer the email thread grows. The best antidote to
negative communication is to get the facts out there as quickly as
possible. Compose a thoughtful and precise "Reply All" with a handful of
relevant facts to get everyone in sync. Then, kill the thread and take
it offline.

Tip 3 - Stop the Bad Press
Most talk on the grapevine is harmless, primarily serving as an
interesting diversion during a long day at work. People don't really pay
that much attention to it. However, innocuous gossip can turn into
hurtful and malicious slander. You need to track down the source of that
information immediately and make it stop. Find out why someone feels
compelled to put forth such negative propaganda about your project and
deal with it face-to-face.

Tip 4 - Fill the Vacuum
You may have projects that aren't impacted by negative
communication. However, you are left with a vacuum of communication.
It's up to you to fill this void with positive and factual information
about your project. Send out pertinent emails, give appropriate updates
at company meetings, and have one-off conversations. That way, people
will really have something to talk about when your project gets tangled
up in the grapevine.

The grapevine has been around since
the time the 3rd person walked on this Earth. There's nothing you can do
to stop it from happening, so include it as part of your unofficial
communication plan. You'll notice a big difference with the buzz on your
projects.

Takeaway: When
CXOs ask developers whether they can move their application to the
cloud, these are the six factors they should think about before
answering that question.

In the last several years, moving applications to the cloud
has gone from a big risk that only a few companies could justify to a
sensible alternative to self-hosting an application. Here are some
things you need to look at to determine if your application can or
should be moved to the cloud. Perhaps only one or two of them stand in
your way, and you can re-engineer those.

Network needs

If your application needs a high bandwidth or extremely low latency
connection to systems within your network, it is not likely to be a good
candidate for being moved to the cloud, unless you can also move those
other systems to the same area. On the other hand, a good cloud provider
is likely to be able to provide high bandwidth, low latency delivery to
your users if they are not in-house users. Maintaining that kind of
network is a headache, and it can be a joy to let someone else deal with
it. The more you can keep the data transfer to being within the
application and not between the application and the screen, the more
suitable your application is for the cloud.

Publicly usable

If the application will be used by people outside of your
organization, moving your application to the cloud gives you two major
benefits. First, it moves your network needs off of your network.
Second, it creates complete separation between your internal network and
your application. While many IT departments will do this anyway, I have
seen IT departments that have not done it (often for good reasons),
which creates a security risk.

Scaling needs

Applications that need to scale or that may need to scale are good
candidates for the cloud. One thing the cloud can do really well is
provide you with resources on-demand. Advanced providers will have the
facilities to let you schedule additional capacity for peak hours or to
detect high loads and bring extra resources online.

Architecture

Not all applications can just be deployed to a server in the cloud
and run. For example, some applications depend on other systems that
just are not available in the cloud or can’t be located there. If your
application relies solely upon standard, commodity technologies (Windows
or a common Linux distro for the OS, MySQL, Microsoft SQL Server, or
Mongo DB for data, and ASP.NET, PHP, Java, or Ruby on Rails for the
application language), then it is a great candidate for moving to the
cloud.

Storage

One thing I detested dealing with during my various system
administrator jobs was storage. And not just “where do we put all of
this data?” either — even more frustrating than that was backups. To
make it worse, systems would get slow, and the issues were traced to I/O
speeds, but solving those issues was not the easiest or the cheapest
thing in the world. Applications that have demanding storage needs are
the kind that are nice to send into the cloud.

Business model

Cloud providers almost universally charge based on the resources you
use: storage, number of servers online for how long, bandwidth, and add
modifiers based on the capabilities of those resources (the more RAM per
virtual machine the more you pay, for example). If your business model
cannot monetize your users in a way that scales with your cloud costs,
you are going to be sunk quickly, unless your profit margin is so high
that all but the heaviest users are profitable, and heavy users need to
be rare. Things like perpetual licenses are deadly when you are paying
for cloud resources on a monthly basis.
J.Ja