The CRAM HR Management Model

Never lose sight of the fact that the members of your project team are
human beings, with aspirations, strengths, constraints, and weaknesses. Your
project’s success hinges more on team members’ attitudes and aptitudes than it does on your Gantt chart wizardry and project tracking prowess. Feel free to manage the project, but don’t forget to lead the team.

Many of us manage projects in a matrix environment with team members
reporting both to us and to a department manager. We do not have human
resources (HR) hiring/firing/evaluation responsibility for them. However,
don’t abdicate responsibility for the care and feeding of the people on the team to managers in the HR or functional hierarchy.

Many of those managers get promoted based on technical knowledge of
human resources or their departments, not on their ability to inspire people.
Your project’s success depends on your ability to lead. There are many books
available on leadership. Read voraciously.

Everyone on your team wants to contribute, learn, and achieve. It may be challenging at times to dig deeply enough to find this desire in some team members, but it’s what makes software project management challenging and fun.

Hold one-on-one conversations with your team members regularly. Determine
what their issues are, ask them for ideas, and give them a voice in the
project. Take their input seriously and act on it.

Ask your team members what they want to be when they grow up. Seriously.
We all have career aspirations. Be the one mentor who cares about their
careers. You’ll be amazed at how powerful this can be.

Be open, honest, and direct with team members. Provide feedback on a regular
basis, not just at review time. Focus your feedback on the behavior, not the
person. Again, management literature abounds. Study.

When you have a performance issue with a team member, apply the CRAM
model: Constraints, Resources, Aptitude, and Motivation.

Project managers frequently diagnose poor performance as a motivation problem.
The CRAM model suggests that motivation is the last issue to consider. A team member may be experiencing constraints in his life that limit his effectiveness.

Examples include getting divorced or married, having kids, fighting addiction issues, etc.
Team members may not have the resources necessary to contribute at their
highest level. Examples include no quality assurance (QA) test environment,
or ancient hardware. Perhaps budget constraints limit the ability to establish
testing environments or buy licenses for necessary software.

Perhaps the domain expertise (business analyst, customer, end-user) is not accessible. Your team member may not be cut out for the role he/she fills. He may not have the programming aptitude necessary for this project. If so, find another project role, if possible. Alternatively, find another team where he can leverage his strengths.

Motivation is the last lever to jiggle when a team member has performance
issues. It should only be considered once the constraints, resources, and aptitude problems have been addressed.

Be a leader and connect with the individual human beings who comprise your
team. The results may surprise you.

Introduce a More Agile Communication System

Most retrospectives of failed projects place a great deal of blame
on communication breakdowns between software project managers, team
members, and stakeholders.

Project managers are taught to mitigate communication breakdowns between team members, and provide constant, effective communication. The weight of this responsibility sometimes leads project managers to overreact. They blur the line between essential, concrete communications and those where the content‐to‐noise ratio actually harms project progress instead of helping it.

To solve this problem, many software development endeavors are moving
toward a more flexible, agile process. The key to agile methodologies is timely
communication loops that enable agile teams to respond effectively to unforeseen changes, and quickly reassess and reprioritize project features.

How do agile project managers keep communications limited to the essentials?

They promote the daily “15-minute stand‐up” meeting. It entails developers
describing what they’ve accomplished since the last standup, what
they’re planning to accomplish “today,” and any impediments they foresee in
reaching their goals. The negative risk of a stand‐up meeting is that it may
rely solely on the precision of each developer’s self-assessment. The solution?

To make stand‐up meetings more effective, integrate a task management tool
that can show the output of a feature’s tests. A tool does not lie about the state of a project’s codebase, and testing results are a valuable addition to developer self-assessment. Presenting report data correlating a feature to a set of tests it passed gives a more accurate representation of the state of the feature.

For example, results from a continuous integration tool can paint an objective
picture of progress. This reduces the stand‐up meeting communication to
the essentials: reporting of impediments (hopefully, already caught by the task
management tool) and unforeseen developments due to edge cases, integration challenges, and bugs/defects. By reflecting these development “discoveries” through a shared, globally accessible tool, developers gain a greater level of feedback precision. Often, unseen connections between features and tasks can be discovered early.

One typical misconception is that synchronous communications are always
more effective than asynchronous† communications. Adding development
tools and short, asynchronous communication loops can effectively supplement face‐to‐face communications.

At a more general level of feedback, a wiki system can easily keep the vision
of the project adjusted to the reality of the development progress. Such a system can also make information available in a timely manner and provide a
higher‐level channel to communicate to stakeholders-at-large, who might not
be interested in the deep, technical details impeding a particular feature’s progress.

By contrast, a software developer’s vision of the overall project can be
blurred over time by the minutiae of his daily technical work. A wiki is an effective way to keep a clear, shared vision of the project among all the participants.

By attacking the problem of keeping information loops tight and noise-free,
software project managers can help avoid the breakdown in communications
typically blamed for project failures. A project manager’s responsibility and
challenge is to streamline the feedback loops at every level of a project.

The 60/60 Rule

We often pretend that software development is the most important part
of the software life cycle. Methodologies abound for development. Books,
magazine articles, and blogs focus on development. Development, however, is
just not where the money is.

Fully 60% of the life cycle costs of software systems come from maintenance,
with a relatively measly 40% coming from development. That is an average, of
course.

The actual cost of maintenance may vary from 40% to 80%, depending
on the system type and the environment it is deployed into. During maintenance, 60% of the costs on average relate to user-generated enhancements (changing requirements), 23% to migration activities, and 17% to bug fixes. The 60% of life cycle costs related to maintenance, coupled with the fact that 60% of maintenance activities relate to enhancements, gives us the so-called 60/60 Rule, one of the few proposed “laws” of software maintenance.

Migration activities include moving systems to new hardware or software environments.

Migration is, of course, a type of changing requirement. Factoring
that into our estimates points out an interesting fact: over 80% of maintenance activities relate in some way to changing requirements.

Naturally, the ability to change code suggests that one should understand it
first. Understanding changes to be made is a major activity during maintenance.

Roughly 30% of total maintenance time is spent on understanding an
existing software product. The development of understanding applies to all
forms of maintenance: changing requirements, migration, and bug fixes.

Understanding is a cost we must pay to maintain code that someone else wrote, or we wrote long enough ago that we no longer have an intimate knowledge of it. During maintenance, understanding code takes the place of new design work found during development for most tasks.

The 60/60 Rule should prompt us to rethink the focus of software development,
as well as maintenance. The tendency to address development activities
may not yield the most impressive gains.

Boehm’s early assertion in the early 1980s that proper software engineering discipline can reduce defects by up to 75% may be true (although I seriously doubt it), and became the basis for much work toward development methodologies, but so what?

A good methodology may reduce bugs (17% of the total maintenance effort), but not address migration, enhancement time, or cost at all. To reduce maintenance costs, we have to address the costs associated with understanding code, adjusting code to new requirements, and/or migrating code to new environments.

The 60/60 Rule suggests that we should focus our efforts on creating systems that are maintainable. Our software must be designed to change so systems become flexible in the face of new requirements. Designing such systems is one of the next great challenges in software engineering.

We know at least part of the answer. The software components need to become less tightly coupled with one another, much the way the components of the World Wide Web are bound together at the last possible moment and in a flexible manner.

Developer Productivity: Skilled Versus Average

Let’s debunk some of the myths about developer skills for project managers
who have been assigned for the first time to software projects.

Understand that really good software developers are much more productive than average ones. In fact, some statistics say that really good developers are multiple orders of magnitude better than poor ones. One order of magnitude is the same as multiplying a quantity by 10. The point is, a skilled programmer isn’t just a little better than an average one; the difference is huge.

What should this mean to our newly minted software project managers as they
plan the development of this product? Managers erroneously think that even if
you can’t get the best and brightest, you still get some usefulness out of mediocre developers. But building software isn’t like digging a ditch, where even the poorest ditch diggers can make a hole.

In software development, what is programmed today becomes the foundation for tomorrow. If you have mediocre developers building your foundation, the really good developers have to go back and fix the flaws before they can movon. Hiring mediocre or average developers slows project velocity. Frequently, taking a poor performer off the team is more beneficial than adding a good one.

Couple this with the fact that adding people to a late project makes it even
later, and you can understand why most enterprise development moves at a glacial pace. The nonexperienced software project manager might reason that if adding more warehouse men allows a truck to be loaded faster, hiring additional programmers would shorten the time necessary to complete a software project.

That won’t work. It will take time, and pull other programmers off-task, to
get the new guys/gals up-to-date. In addition, the communication channels
increase with each addition to the team. With a team of two, there is one channel: Betsy Sue to Bill. Add Mike, and you jump to three channels. The number of channels continues to grow exponentially.

Here’s the formula: 
n(n–1)/2. With 12 people on the team, you have 12(12–1)/2
channels, or 66 relationships you must maintain as the project manager. Add
one more person, and you now have 78 communication channels to oversee.

Building software with average developers exposes two project myths:
1) that you can shorten a project by adding people, and
2) that it’s OK to have average developers produce average (buggy/off-task) code at an average pace. In truth, average developers drag overall productivity down and the project takes longer than necessary to complete.

The solution? Give good developers powerful tools. You’ll get higher-quality
software faster. Second, having warm bodies doesn’t help projects, and having
to babysit poor developers cuts the productivity of your good developers, who
are craftsmen. Software is too complex to turn into an assembly-line manufacturing
process.

Want faster software development? Spend the extra money to hire and nurture excellent software developers. It will pay off in both the short term, and in the long term when it’s time to maintain the code.

You Aren’t Special

Remember what your Mom told you? “You’re special! You’re unique!”

Right, just like every other boy or girl who had a mom! Believing that loving
lie leads to common software project problems.

I coach many different teams. Without fail, the teams who believe they’re “special” are always behind when judged by how well they meet their software
project metrics. Because they think they’re special, they have a strong inclination to reinvent everything.

They think, “No other team could have possibly developed usable software, or at least not as outstanding as what we create among ourselves.” Instead of learning from the mistakes of other developer teams, they insist on making their own mistakes. Over and over and over. At company expense.

They spend so much time rewriting, debugging, and putting their own twist
on software and tools that are already industry standard that they never finish
customer projects. The ones they should sell to people for money. Those
mythical, magical products that would be as special as the team, if only it ever
got them written.

To hear this unique group of developers tell it, there are no existing build systems that can handle their “one of a kind” requirements. So, they must write a new one for each new project.

Instead of reusing an existing object-database mapping tool, they write their own. Web application framework? We can do that, they profess. Continuous integration? Check. Testing harnesses? Let’s write those, too. The vainest and most disillusioned of them will even attempt to write their own programming languages.

So how do these teams spend their day? Solving the problems they’ve created
by substituting the untested code they built themselves for the fully functional
software tools usually available to them for free.

When they write their own database layer, they spend the days tracking down obscure performance bugs and caching issues. Handling the edge cases† ends up consuming more time than they ever would have spent learning, or even modifying, existing tools.

The reason less “special” (but more successful) teams use existing tools is
because the problems they’re setting out to solve are hard problems. They need reliable tools so their attention is focused on the solution to their software project, not on trying to refill an already brimming toolbox.

What does this have to do with effective software project management? Don’t let your programmers reinvent the wheel. When they come to you explaining how special their problems are, point out that their mothers may have stretched things when they made that “you’re special” assessment. Be knowledgeable about what’s available and guide your team toward high-quality open source or commercial tools.

The “not invented here” syndrome derails so many great teams. Don’t let it derail yours.

Add Talents, Not Skills, to Your Team

I used to hire the way everyone in our industry hired: skills, skills,
skills. One day an interview candidate threw cold water in my face, figuratively,
and it changed me.

I was looking to add a new hero to my team, someone with years of Microsoft
experience. Looking over Bill’s resume, I could tell he was perfect for the position.He had over six years of experience in all the relevant skills. If I could hit the right price point, this was going to be easy.

Bill came in for the interview. We talked and I described the projects we had
on tap, and what a perfect fit Bill was for this position. I was sure this was going well. Suddenly, I realized I wasn’t going to get him. I stopped the interview in mid-stream and asked Bill what had happened. I told him he was perfect for the position, but that I sensed he wasn’t coming.

His response was, “Rich, if I wanted to do what I’ve been doing the last six
years, I’d stay where I am. I heard you had some cool, new Java projects coming up and I wanted to work here because I saw it as a chance to learn and grow.” That’s when it dawned on me. Hiring by running a “resume versus skills”
match is the stupidest way a manager could ever build a team.

You see, my partners and I got into the high-tech industry because we
wanted to be at the leading edge of technology. None of us hoped to spend a
career recycling the same skills we learned in college. We got into this game
because it would always be about new frontiers and learning new techniques
and technologies.

But somewhere along the way, things went horribly wrong. I realized we had
stopped investing in our employees’ growth. We weren’t looking for fresh, new
talent. We were looking for very specific, already refined, skills. Now, I tell
people that if they see an employer hiring for an exact skill match, what that
employer is really saying is, “We don’t plan to invest in you.”

My advice to anyone seeking to build a strong team is to hire for talents, not
for skills. What talents do I look for when hiring technologists for my agile
development teams? Good kindergarten skills:

• Do the candidates get along well with others?
• Do they play nice?
• Do they put their things away when they have finished playing?
• Are they excited about new things?
• Do they like learning?

I can teach skills. In fact, in our agile team environment, learning technology
is fast and easy. However, it is nearly impossible to teach an adult how to play
nice.

Hiring for talents, not for skills, is a radically different way to build a team.
However, I want to work with those who are poised to move enthusiastically
beside me into exciting, new future technology.

Favor the Simple Over the Complex

As far as I’m concerned, my microwave oven only has one button: “add a
minute.” To boil a cup of water for my coffee, I press the button three times. To melt cheese on my crackers, one click. To warm up a flour tortilla, I press “add a minute” and then open the door after 15 seconds.

Would a one-button microwave oven ever make it out of the planning committee?

Probably not. I can tell by the (never used) features on my microwave
that the committee favored complexity over simplicity. Of course, they probably cloaked “complexity” in the euphemism “feature-rich.” No one ever starts out with the goal of making a product that is unnecessarily complex. The complexity comes along accidentally.

Suppose that I have a slice of cold pizza that I want to warm up. According to
the manufacturer’s directions, I should press the “menu” button. I am now faced with the options “speedcook” or “reheat.” (Um, “reheat,” I guess, although I’m kind of hungry. I wonder if speedcook will be any faster than reheat?)

“Beverage,” “pasta,” “pizza,” “plate of food,” “sauce,” or “soup”? (I choose “pizza,” although it does have sauce on it, and it is on a plate.) “Deli/Fresh” or “Frozen”? (Neither, actually—it’s leftover delivery pizza. I’ll choose “Deli/Fresh,” I guess.)
“1 slice,” “2 slices,” “3 slices,” or “4 slices”? I have no idea how much longer this interrogation will last, so I press Cancel and then the “add a minute” button.

What does this have to do with software development? As far as I’m concerned, Amazon.com only has one button: “one-click purchase.” Oh, sure, I had to type in my address and my credit card number the first time I visited, but now I am one click away from my impulse buy.

Software generally solves complex problems. The question is how much of
that inherent complexity are you forcing onto the end-user? Is your software a
complexity amplifier?

Great software is generally a complexity sink—it bears
the brunt of the problem on behalf of the user instead of passing it along.
As a software project manager, are you a complexity sink or a complexity
amplifier?

The best ones absorb complexity from all sides—from the programmers,
from the end-users, from management—and never amplify it. As the
end-users generate seemingly contradictory requirements, your job is to help
clean them up, rather than passing them blindly on to the developers.

As the developers cite arcane technical reasons for not being able to fulfill a requirement, your job is to translate (absorb) that complexity and present the endusers with enough information to help them choose a different path.

How easy is it to use your application? How easy is it to add a new feature
to your application? How easy is it to request a new feature? Report a bug?
Deploy a new version? Roll back a bad version?

Simplicity doesn’t happen accidentally. It needs to be actively cultivated. Complexity is what happens when you aren’t paying attention.

Positioning

The basic idea of positioning is that your product occupies a place in the
mind of the people in your target market. You are defined by their perceptions
of you.

Let’s try to explain this by using an example:

Windows XP has a position that I would describe like this:
The most popular operating system for desktop PCs

The first thing to notice is that when you describe a position, the first
word is usually the, a definite article. Only one product can occupy a
given position in the mind of the market.

Describing a position has three important parts:

• First, describing a position almost always includes a superlative
of some kind. In this case, the superlative is most popular, but I
could have said number-one. Often people can remember only the
first and best thing in a category. Being number six in your
market segment is probably not a position at all.

• Second, a position will describe what label the market places on
your product. In this case, the label is operating system, which
fits just fine. If there is no label that fits your product, you have a
big problem. If the market cannot compare your product to
something else, then you don’t have a position.

• Third, the position will have qualifiers that define exactly what
group of people has this perspective of a product. In our example,
the market segment is for desktop PCs. This position doesn’t say
anything about operating systems for enterprise servers or mobile
phones.

Another view of positioning is to ask in which market segment you want
to be known as number one. You want to be known as the best of your
breed, even if you need several qualifiers to constrain the scope of your
claim. Don’t think about being fifth place in a large market. Instead,
be number one in a smaller market. Apple’s Macintosh is a distant number
two in desktop computer platforms, but it is number one among
graphic designers.

The Algorithm for Finding an Idea

Many entrepreneurs search for a product idea using an algorithm that looks something like this:

Idea FindGoodProductIdea()
{
Idea candidateIdea = null;
while (true)
{
candidateIdea = new Idea();
if ( candidateIdea.IsGood() )
{
break;
}
}
return candidateIdea;
}

This algorithm frankly doesn’t work well at all, for three reasons:

• It’s inefficient. Every time through the loop, your brain has to
make a context switch between being creative and being
analytical. These context switches waste a lot of your mental
CPU time and slow you down.

• It generates too few results. The context switches prevent you
from ever getting a really good flow of ideas.

• It’s buggy. This algorithm forces you to evaluate every product
idea in isolation. Sometimes an idea doesn’t reveal its potential or
its pitfalls until you’ve had plenty of time to think about it.

Using this algorithm is the best way to not find an idea or to settle on a
bad one. A much better algorithm looks something like this:

Idea FindGoodProductIdea()
{
ArrayList candidateList = BrainstormLotsOfIdeas();
return ChooseTheBestIdea(candidateList);
}

In this approach, you will spend a lot of time up front building a list of
ideas. This is the step where you apply creativity, thinking with an open
mind and diverging into all possibilities.
After that, you spend a lot of time choosing the best idea from your
list, thinking more analytically, and converging onto the one idea that is
the best fit for the kind of product you want to build.

Ten Effective Ways to Market Your Product/Services

Build Trust with Your Customers

Certain customers may buy a product or service from you on impulse, without

knowing much about your company, but will they come back? To attract

the best customers to your business — those who generate referrals and buy

regularly from you — you have to build trust.

How do you build trust with your customers? Customers trust your business when

_ They sense that you know what you’re talking about.

_ You give them a suggestion that actually works.

_ You understand what they want and give it to them.

_ You do what you say you’re going to do.

Trust is something your business has to earn, but the effort is worth it because

trust pays back big time in the form of loyal customers who tell their friends.

Tell an Interesting Story

To market your product or service effectively, you need to tell catchy stories

that make the news and capture people’s attention. For example, how did Ben

and Jerry’s crack the tough premium ice cream market? It wasn’t just

because the company has great ice cream. It was because it had a great story

to tell. Ben and Jerry’s is a Vermont company owned by people from Vermont

who put their hearts and souls into their ice cream. And they gave their ice

cream personality with creative names such as Cherry Garcia, Phish Food,

and Chunky Monkey.

Become Effective at Web Content

The primary reason customers come to your company’s Web site is for

information — they want to find out something, and find it quickly. To provide

effective information for your customers, you need to know who your customers

are. Your Web site’s tone should reflect what your customers feel comfortable

with. Unfortunately, this is precisely where most business Web sites fail their

customers, because they don’t know how to give customers what they want as

quickly and concisely as possible

Utilize Affiliate Marketing

One of the best ways to creatively market your company and its

products/services is to market on the Internet. That in and of itself isn’t creative,

but if you find interesting ways to link to other companies’ sites that

are compatible with yours — called affiliate marketing — that is creative. 

For example, suppose your company is in the travel business; you target large

corporations to get their retreat and conference business. You should

approach the top retreat and conference companies and convince them to

put a link on their sites to your travel site, and vice versa. 

That way, when an event planner at a large corporation is perusing conference sites, he or she

can easily come to your site to get the details and make travel arrangements.

Be careful about trying to be everything to everyone. You don’t want to put

links on Web sites that don’t show your company in a positive light. 
Likewise, you don’t want ads for unrelated products and services on your site. If, for

example, your Web site is about do-it-yourself shelving, you don’t want to

confuse your customers with ads for videos or domain names.

Consider Mobile Marketing

Is it time for you to take your company’s marketing efforts to customers’

mobile devices? Actually, most of the research done so far has found that half

of customers are in favor of mobile marketing and half are against it. The half

who appreciate mobile marketing are the teens and 20-something groups, but

only when the information is relevant to their needs and interests and presented

in a compelling way.

The Mobile Marketing Association (www.mmaglobal.com) believes that this

form of marketing reaches people when they have nothing better to do than to

look at their cell phones or PDAs (personal digital assistants). The question is,

how do you know if your target customers are happy to hear from you? You ask

them! Holding some group interviews should give you the answers you need.

The only thing known for sure is that the 18- to 34-year-old age group has

their mobile devices with them all the time. They like music and video games.

So, if your marketing campaign is targeting this group and you can incorporate

music and/or video games and send them to their mobile devices, you

may have a winner.

Give Your Product Away

So, you want to make a lot of money and you have a great product or service

to offer. Why not give it away to customers? No, we haven’t lost our minds;

we’re serious. That’s how Netscape started. Microsoft as well. This strategy

isn’t new; for example, Gillette, the razor company, followed this strategy

years ago. It gave away its razor knowing that its customers would continue

to come back to purchase the blades — the consumable part of the product.

You need to decide what you must sell and what you can give away. Every

company has something it can give away, even if only for a 90-day free trial.

Free sampling is the quickest way to get customers to try out your products

and services. Certainly the big consumer-products companies such as

Procter and Gamble know this because they spend millions each year to

sample new products and services to customers.

Just make sure that the product you give away has a consumable aspect to it

so that your customers need to come back to purchase new products — such

as new blades, new ink cartridges, or new coffee capsules.

Make Customers Your Marketing Stars

Your best customers are true testimonials to your company’s success, so

why not put them in the public spotlight and let them shine! For instance, if

you sell to other businesses, you can feature their companies and how they

use your products or services on your Web site, in your newsletters, and in

your television commercials.

Many successful companies, such as Microsoft, IBM, and Kinko’s, use this

marketing tactic. What better way to show everyone that your customers are

important to you? Let them benefit from your advertising along with your

company.

Build Relationships, Not Sales

To be successful in business today, you need to build long-term relationships

with your customers and interact with them in ways that will make the relationships

better for both parties. The nature of marketing has changed radically

as a result of mass customization and technology, which have made it

possible to reach individual customers and give them exactly what they

want, when they want it

Building long-term relationships doesn’t mean sending customers questionnaires

on a regular basis. You want to give customers easy and interesting

ways to converse with your business so you can really understand their

needs.

For example, Lexus invites its best customers to a special black-tie

reception when its new models come out; Porsche, on the other hand, invites

its best customers to try out new models on the racetrack! During these

events, the companies can get feedback in a relaxed environment and make

sure that customers and salespeople interact as people. When it comes time

to purchase a new vehicle, the customers will want to deal with people they

know. In your business, look for ways to build long-term relationships, and

the sales will follow.

Get Your Customers Emotionally Involved

To get your customers to pay attention to what you’re selling, try using

advertisements that tell a quick but memorable story — a story that gets

your customers emotionally involved. If you’re fortunate enough to be selling

a product that gets people excited while it just sits on the shelf (how about

that iPod you just bought), this advice isn’t for you. However, most businesses

sell products that don’t generate a lot of enthusiasm without some

effort on their part.

For example, Home Depot came up with a marketing plan to try to sell power

tools to husbands who want to convince their wives that they need them. In a

commercial, a husband points to a power drill and proclaims, “This is your new

kitchen!” The ad definitely makes a strong case for the purchase of a pretty

boring item. You can make any product or service interesting and connect

emotionally with your customers if you look at the product or service in a

new way.

Guerrilla marketing

Organizations in today’s marketplace have become faster and more flexible,

and companies increasingly are aiming their products/services at specific

niches of customers. As a result, the traditional ways of marketing are becoming

less and less effective. In their place, advertisers are adopting techniques

that are unconventional by traditional marketing standards.

Guerrilla marketing is the label applied to this particular brand of marketing.

According to Jay Conrad Levinson, the guru of guerilla marketing and author

of Guerrilla Marketing, 4th Edition: Easy and Inexpensive Strategies for Making

Big Profits from Your Small Business (Houghton Mifflin), this new approach

can be summed up as

Achieving conventional goals, such as profits and joy, with unconventional

methods, such as investing energy instead of money.

Levinson, being the guru that he is, has developed five rules that reflect the

guerrilla marketer’s view of the world:

_ The 10/30/60 rule: According to Levinson, you should invest 10 percent

of your marketing budget to talking to everyone in your marketing universe

 whether or not they match your customer profile. Use another

30 percent of the budget to convince people who match your customer

profile — your prospects — that they should become your customers.

Devote the last 60 percent to marketing to your current customers —

producing the most profits at a lower cost per sale.

_ The 1/10/100 rule: This rule says that $1 spent communicating with

your staff is equivalent to $10 spent communicating with the trade,

which is equivalent to $100 spent communicating with your customers.

In other words, communicating to your employees can be the most costeffective

way to transmit your marketing message to your prospects and

current customers. Train all your employees to be familiar with your

products and services, so they can accurately tell others about them.

_ The rule of thirds: According to Levinson, one-third of your online marketing

budget should go to designing and posting your company’s Web

site; one-third should go to marketing the site offline; and the final third

should go to improving and maintaining your Web site, keeping it entertaining

and fresh.

_ The rule of twice: This rule says that remaining truly competitive online

will cost you twice as much as you think it will cost.

_ The rule of the ruler: This rule states that although you can delegate the

marketing function to others in your organization, you can’t delegate

the passion and the vision that you feel for it. To ensure marketing success,

take command of your company’s marketing process and keep

a close eye on it, regardless of who’s in charge.

Are you ready to supercharge your marketing efforts? Give guerrilla marketing

a try — it could make a difference for you. For more information about

guerrilla marketing, check out Levinson’s Guerrilla Marketing Online Web site

at www.gmarketing.com.

Revolution of Competitive Intelligence with Semantic Real time Data warehousing

Semantics is the study of meaning in communication, including the meaning

(or an interpretation of the meaning) of a word, sign, or sentence. How many

times in the middle of an argument have you heard the phrase, “Let’s not

argue about semantics”? Linguists and semanticists have been dealing with

semantics for a long time. However, in the world of computer science, semantics

are relatively new.

In May 2001, Tim Berners-Lee, James Hendler, and Ora Lassila authored an

article in the magazine Scientific American titled “The Semantic Web.” You

can find the article here:

www.sciam.com/article.cfm?id=the-semantic-web

In the final line of this article, the authors state that the Semantic Web will

open up the knowledge and workings of mankind to software agents —

productivity applications that will perform analysis on our behalf.

With this article, The Semantic Web era began. The Semantic Web is about

two specific technical standards:

✓ Common integration formats: The Semantic Web uses common formats

to integrate and combine data drawn from diverse sources. The original

Web mainly concentrated on the interchange of documents.

✓ Language for relationship mapping: The Semantic Web uses language

to record how the data relates to real-world objects. These records

allow a person, or a machine, to start off in one database, and then move

through an unending set of databases connected by a common subject.

These two concepts can be applied to data warehousing and business intelligence

efforts.

I think there is new big opportunity for businesses; we can use real time data warehousing and analyzing real time data, transferring to information and make information in action (knowledge).

20 Qualities of an Agile Leader

Teams of all natures - agile software development or otherwise - need inspirational leadership to perform their best.

That leadership may, or may not, come from the organisation's appointed leaders. But all teams need it, nevertheless.

So what are the qualities of inspirational leaders?

1. Strong communication – storytelling and listening
2. Passion for learning and intense curiosity
3. Focus on developing people
4. Having fun and very energised
5. Strong self-belief, coupled with humanity and humility
6. Committed to making a significant difference
7. Clarity of vision and ability to share it with others
8. Dogged determination and often relentlessness
9. Strong focus on priorities
10. Not afraid to show some vulnerability
11. Regular use of reflective periods to think and learn
12. Real passion and pride in what they do
13. Confidence and trust in their teams, giving them real empowerment
14. Respect for all (team members, temps, customers, suppliers and directors alike)
15. Clear standards of ethics and integrity; openness and honesty
16. Ability to drive, inspire and embrace change and continuous improvement
17. Positive attitude at all times and an innate ability to be diplomatic in any circumstances
18. Lateral thinking and ability to find innovative ideas and solutions to problems
19. Ability to inspire and motivate others
20. Willingness to take (calculated) risks

These are qualities that differentiate good leaders; people others would be willing to follow.
These are also qualities of 'servant leadership'. An admirable leadership style that is particularly emphasised in agile software development methods.
How many of your team - or appointed leaders - demonstrate these qualities; the qualities of inspirational leadership?... and if you work for me, please don't answer that :-)