Earning respect and money with Joomla

CMS implementation is difficult, but great to be involved with. How good you are technically, how socially connected you are, what a honest and hard worker you are - it doesn't add to the respect & money you receive.

This chapter deals with what you should and shouldn't do to make a living with Joomla! implementation and support.

The things that do count in earning respect and money:

  1. be firm but sympathetic;
  2. Deadline first, flex the scope;
  3. Sell and negotiate continuously;
  4. Define roles and play them!

Why me?

Do you ever:

  • have customers that don't pay your invoice?
  • work twice as much as you're getting paid for?
  • have a big misunderstanding about the deliverables with your customer?
  • encounter disrespectful behavior of clients?
  • frown upon the choices customers make in your field of expertise?
  • get no or low appreciation for what you've delivered?
  • need to battle scope creep?
  • take much longer to deliver, but the customer did not care?
  • discuss with your partner wife or husband about whether it's a good idea to continue your firm
  • think of going back to a normal and easy job?

You are not alone.

If all the answers are 'no' you are natural talent in earning respect & money with open source CMS expertise.

Or you've worked through this chapter before?

Denial

After years of long days and hard work, you only find your soul mates at open source congresses and meetings. Where we share our experiences. Or via the IRC channel, where we like to complain about our customers: they're stupid, they don't want to pay, they think they know it all, they expect you to go to work without them putting pen to paper, and so on.

What's happening here is that we are in denial. The customer is not the problem. We ourselves have to change our attitude.

"I'm not good at selling, I like to build systems."

Fair enough, but did you start up your own organization to be in charity work? Charity workers get respect and "sell" their free help.
If you have decided to start your own firm, not selling is not an option. You have to get off the wrong bus quickly.

"I'm not what you call a salesperson - I'm too soft. To be honest: I hate selling."

You need a change in how you perceive the world. Selling is a profession that should be indicated as "assisting with purchasing". Put aside your prejudice! Start assisting your customer in purchasing the right things (instead of selling), and teach them how to give you the respect and treatment you deserve, plus payment.

"Larger organizations don't contract small firms on their bigger projects."

Play their game, play it well and they will hire you.

"My customers don't work this way."

Well, then get a different type of customer, or teach your current customers ''how it works''.

"There is not much money to be made in open source"

On the contrary: Open source integration has at least five major innovational effects that closed source can't beat. Proven and indisputable. For that reason long term or short term replacement propositions of closed source by open source ''are'' big money. Just because closed source is about big money. Closed source will eventually adapt itself to open source innovation. But that will take time. In the meanwhile, your expertise is worth respect & money. If your have not been convinced yet, click the link above about the said innovative effects of open technology because you need to ooze pride.

Still in denial?

Sorry for bothering you! Please continue your good work and put your mind at rest with the other chapters you'll find in this book. One last request: could you please efface yourself quietly, poor and lonely? :-)

The other chapters are very much worth reading. Don't get me wrong. Don't however lull yourself to sleep by obtaining more technical knowledge only as a distraction from a totally different ballgame: earning respect & money. Because that's got nothing to do with Joomla, Drupal, TYPO3 or any other world class open source CMS, nor your great expertise.

Awake? Good, we need a clear mind to learn & practice how to earn respect & money with our expertise & means.

Three thing you need to be aware of all the way through

  1. Your reputation
  2. Your role(s)
  3. Your task(s)

Add a. Your reputation

In general, the reputation of IT workers can be found at the low end of the spectrum of respected jobs. Not sure you agree? Try it!

  1. Wear a suit, start talking of a business proposition to anybody. Suddenly switch to the details of a possible IT-implementation of that particular proposition. Your credibility decreases instantly.
  2. Mention your IT-profession at a party to (female) young urban professionals. Just look at the faces.

Add b&c. Your roles and tasks

In organizations, our IT-job is to persist in constant expectation management, infinite selling and sticking to plans

The good news is that there is a lot of material available detailing the process of a web system implementation. The bad news: help, humans are involved!

Problems are those weird things that pop up when you don't have your eye on the ball: earn money and respect.

First some definitions

Resource

A resource is pending input from a customer or third party. If you don't get the resource, you can't do or finish your job. E.g. digital photos from a photographer, a list of menu-item names in a different language, a signature on the contract of your assignment (oops, you never ask for that?), etc.

Resourceplanning

Ensuring that the input of customers and third parties is ready for use in a project or support.

Scope

The extent of a solution. The size and magnitude of an effort, expertise, machinery, functionality that is wanted/planned to offer that solution. <google scope - wikipedia>

Functionality-blocks

A logical group of functionality under a common title. Expressed in normal ''homo sapiens'' language. E.g. a forum, design, interface,  advanced search. (A homo digitalis would invent titles like Jom-social, psd plus html/css and template based on wire frame, database lookup of indexed content.)

Release plan

The release plan specifies which Functionality-blocks are going to be implemented for each system release and dates for those releases. The release plan specifies who (in which role) fulfills the particular tasks.

Sprint

All efforts within a certain phase in a project (as agreed in a release plan). The word "sprint" suggests running to a deadline, no time to lose. We have to catch an airplane in time. Because the airplane will leave and we better be on it. And therefore we might not pack our bag that well, some items might be missing, we might go in fits and starts, but we get there in time! By doing so, we are much better off than having all stuff beautifully packed: everything we might need is packed in the suitcase, but we are left behind on the airport.

SprintX

The virtual sprint after the last planned sprint within the release plan. It is a container for extra work (scope creep or agreed out of scope) or waiting area for functionality-blocks that couldn't be implemented in the sprints so far.

Contract management

The management of contracts made with customers, vendors, partners, or employees. Contract management includes negotiating the terms and conditions in contracts and ensuring compliance with the terms and conditions, as well as documenting and agreeing on any changes that may arise during its implementation.The purpose: maximizing financial and operational performance and minimizing risk.

Project management

The discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives. Put it differently: running from A to B without looking up and getting there in time; no matter what.

Findings

How people perceive the world and in an open source web system / Joomla implementation in particular: how people see results in the context of what is agreed. We need to elaborate on Findings a bit more because synchronization of Findings is the key to a valuable contract management.

Findings

Findings are complex. We might have conflicting interests, personal issues versus the roles we play. Different levels of expertise and experience. How well were negotiations perceived. What about respect? Did parties involved that wrote their Findings receive enough respect from others and give enough respect to others during the process? All these factors influence the way we perceive things.

Example: An emotional quarrel with your neighbor hardly ever has to do with the subject or object at hand. Most likely it's something else that formed their opinion, expressed in a sort of "Findings".

Household Psychology one-on-one

Let's also have a quick look at some important psychological effects while doing business. In case of an open source web system implementation, we stumble upon a few interesting effects that have a major impact.

What a customer really wants

Cover and future proof advice. That is it, folks. He/she is not interested in open source, Joomla, you, your product, your measures, your vision, etc. So stop telling them dumb stories and start asking smart questions to secure them in what they really want.

The declining value of service

Everything that is already done, is worth less every following day and everything that needs to be done is very important and urgent. Does it ring a bell?

Always right

A customer is always right. If not, we just have a different opinion on the subject… That is a good example of what synchronization of Findings is all about.

Deadline first flex scope

Projects tend to go over the deadline. Why? Are you such a crappy planner, do you like to disappoint people? Of course not. Do you end up with a buggy result to has to be debugged, do you accept new requirements and changed resources while you are developing? Yes, you do. Do you have a problem stopping development efforts and starting a thorough test? Do you deliver half-baked systems just to "keep the customer happy"? You most probably do. And you should stop this behavior from this moment on.

"Deadline first" means: no matter what, we deliver on time. Read that sentence again: we deliver on time.

40 years of ICT has done us no good in some perspectives. It's perfectly accepted that we don't deliver on time. Even worse: it's accepted that more than 50% of the larger ICT projects world wide are a sheer failure. And we accept that they tend to be twice as expensive in the end than quoted upfront.

Suppose your grocery store would say "no milk today" after you ordered it by phone yesterday. Suppose your bakery would raise their prices from one day to the other by 100% or 200%. What would you say if the constructor of your house that just collapsed sends you the last invoice for "work done to your house"?

Customers in ICT just walk off and mumble their disdain. They go and start another ICT project. And we suppliers? We get away with nonperformance! We don't deliver on time, we don't stick to promises and we deliver systems that will not be used (long enough). Sometimes a customer sues us. But what the hack: you can't get blood from a stone. In many cases, angry customers don't pay the last installment or the main installment (depends on how stupid we were). But that's about it. Easy walk in the park. We continue to next project and act more or less the same…

STOP IT!

Deliver on time, no matter what, no excuses, but deliver!

How to deliver on time

I will now go into detail about how it's done and the positive effects of this behavior for all parties involved, including your customers.

How do you deliver on time?
Most importantly by flexing the scope.

The Basecamp-company 37signals writes in their visionary guidebook Getting Real: open source (and also Joomla) web systems are very well equipped to stick to this rule. (Read the full book for other good rules)

  1. Open source has good prototyping & Proof of Concept capabilities, scope gets clearer ''after'' prototyping and thus scope changes.
  2. An Open source web system has extensive and useful hidden functionality on board, loads of change available (see also Negotiate continuously)
  3. Scope should be flexible because customers change their mind on what they want, after experiencing first results and possibilities. Customers learn on the job. And change their mind accordingly. Scope creep is the negative effect, ''flex scope'' the positive solution.

This is the step-by-step:

  1. Agree upfront that you put deadline first and flex the scope to meet the deadline. Explain honestly what "flex scope" means. Lets call the customers "they". Be very open: what they want now, they don't get in the end. Why not? Why not? Advancing insight will eventually lead to different systems! However they do get what they want in every iteration towards the end result.
  2. Be sure to be in charge of flexing the scope (no discussion, you have to meet the deadline, so you're the one that makes decisions after touching base.
  3. Plan a time buffer in your work towards a deadline. Use the buffer to flex the scope and make an new version of your release plan. Do that by diminishing the number of functionality-blocks in the current sprint, slim down functionality-blocks.

Manage possible frustration of customers

  1. Never write off a functionality block yourself. Place it in a next sprint or in SprintX.
  2. Communicate the flex scope action with a new Release plan
  3. Stick to priorities in the Findings so far and write down every single remark (no duplicates) or new wish explicitly.

Be firm but sympathetic

Main firm stands:

  1. Never ever accept a fixed price contract again. Or make a ridiculous margin on top of your quote. Open source web system development and implementation is just not suited to offer and work with a fixed price. Explore 2Value's alert system as a balanced alternative in between fixed price and "Carte Blanche".
  2. Stick to the rules of engagement: payments overdue? Stop work right away, no exceptions.
  3. Professionalism: start to offer it by demanding it.

Sympathetic behavior accompanied with a firm stand

  • A: Always say and write: We "can't" instead of "we don't want to" or "we won't".
    Example: I am sorry sir, I am afraid I can't continue staging your site to production. The partial payment has not arrived in our bank account. It's company policy to proceed only if due payments have arrived in our bank account.
  • B: Say you can't start this server virus-fix analysis before the money has arrived in the bank account, but let the customer ''feel'' that your back office has already taken measures and is full on the job of analyzing & fixing the bug.
  • C: A support contract is hardly ever a result insurance. Support on webCMS's, especially those based on open source can only be a guided effort insurance. That means: at the most we promise reaction, response and resolve times and capacity available in the required expertise.

Don't introduce this result responsibility of customers site on your business' shoulder. They can't bear it. The load of several million lines of code… someone else's code. Code running on a contentiously changing stack that's attacked by scoundrels every day (hackers).

Remember: Before the customer first rang your door bell, their site was never your problem. Keep that in mind and remind your customer. Some of these customers think they can buy your commitment, devotion, hiring you as a templater for a few hours…. And some of you act like sinners right away when a customer is in great distress and quick to point the finger at you because of a non-operating web system. Again: behave like a professional and they will respect you as a professional. Behave like a low grade assistant, they will treat you as a doormat.

A webCMS is the customers problem and we can assist by improving it and helping out when problems occur. It is not your problem. Comprendo? Tiny difference, huge effect. Only watch the tone of voice.

Having said (and repeated) that, you work your ass off to help this customers web shop to go live again before the rush of Christmas shopping.

  • D: We do deliver exactly what was agreed (no rebate for nothing), but we ''put in the extra mile'' too.

Sell and negotiate continuously

It's obvious that you have to sell a project and negotiate conditions (among them ''price''). What is new to many people is that in a web system development project or the support afterwards, you have to sell and negotiate continuously.

A few examples:

  1. Is it done? Can I send my invoice now? ("No, there is still a few issues left to improve…")
  2. Support request: change a logo on the site. How much time do you need? ("Ooh, come on you can't be serious!…")
  3. You think it is extra work, your customer doesn't seem to think so. ("It might not be in the RFP, but I remember very well us discussing this functionality")

Remember that sales is game. The customer should have the overall feeling that he/she won that game. Give them that feeling and be well-off with the deal at the same time!

To be able to play a game of marbles, you'll need marbles.

How do you get marbles? By signing the contract? No. By sending invoices? No no. By holding back results. Sometimes…

The main source of credits for your sales game are happiness and money. Don't mix them.

  • Build up credits in the emotional bank account of your relations (See Steven R. Covey). Solve frustration you might have; you need to be happy in the work relation too!
  • If partial payments have arrived on time, you have credits for new games.
  • Refrain from having too many service hours unpaid. It makes you vulnerable and clears the way for customers to put you under pressure and/or reopen negotiations. The more they owe you, the more they might throw in these bullshit arguments to not proceed and pay you. Inappropriate pressure is coming down on you. But you caused it yourself in the first place. (See: be firm but sympathetic)

Define roles and play them!

A customer has several broadly accepted roles: the boss, the end user, the administrator of the web system, and most important he/she is the judge.

As a literal 'sole' proprietary holder you stand alone as the supplier of the web system. You have to deliver the system: good, suitable, well documented, within time, within budget en reliable. How fair is that?

Well, that's not fair at all! Lets have a closer look at what is happening here.

Suppose you ooze that "do it all and liking it" attitude. You get questions like:

''Would you advice us to use Joomla?''

and

''Could PHP do the backup cycle for us''

and

''Is it possible to get multilingual support in time?''.

Nothing wrong with these questions, right? How often did you answer them?…without realizing that you just loaded the barrels of a shotgun pointed at you.

Suppose you answer these questions with "Yes", and refined the answer. That's very nice of you! You know a lot! The respect you get originates from the fact that you're not only a good developer, but also:

  • have a very sharp vision on how the selection process should be;
  • feel acquainted and safe with the LAMP stack and cronjob-mechanism and you fix it (woow!)
  • that the international open source community and especially a web CMS Joomla is a sort of homecoming for you; you know a lot of people, anywhere in the world….

'What a man, what a man, what a talented man.

No idea where we're heading? Hold on and ''no worries'', these are just harmless examples to get you to understand the risks of being foolishly responsive.

Lets pull the trigger of the shotgun pointed at you. Remember that it was you that loaded the ammunition:

  • Now wait a minute, you advised Joomla and now we have to program tailor-made code that might solve the issue that Drupal does out of the box?!…'
  • Every night we expected to have a safe copy of our website, because you said PHP was capable of doing it. We paid you to configure the cronjob. And now we ended up with a useless restore…"
  • You promised multilingual support and now we have to pay for it?'

Where did the respect go that you counted on? Why does this customer behave like this? It's obvious that the customer is angry and I guess you have to work for free to make her or him happy again! So what's your best bet, pal?

What went wrong? A few elementary things in conducting professional business. And please don't lull yourself to sleep with

oh, no but I'm just a small firm, a creative entrepreneur, and my customers are small. I do not need this.

A few elementary and universal things in conducting professional business went wrong:

  1. You didn't separate your different talents in distinctive roles. Symbolize them by different colored caps. So from now on: define roles.
  2. You didn't put on the right caps while answering the questions. That made you vulnerable: the customer can take your answer from any point of view. Play your role!

How do you define roles?

You don't have to. Definitions are readily available, just choose a set of roles that match your business and communicate them. Put them in writing and make your customer acquainted with the various roles you play professionally. Examples: account manager, consultant, contract manager, project manager, designer, developer, tester, content-builder, hoster.

A customer or its representative will only abuse you playing 10 roles at a time IF YOU ALLOW THEM TO.

To be safe and sound. Use these roles explicitly at all important times and play them.

I am sorry, ms. customer, as your developer I could never answer your "should we use Joomla" question. The reason is your organization has to choose a webCMS and I can make the best of it. Of course I can connect you with mr. colleague_of_mine, he is consultant at our company and specialized in selection-processes. His fee is very reasonable compared to the coverage of corporate risks he covers with his advice.

PHP for the backup cycle. As a contract manager I would have to say 'no' to you, because a backup procedure is out of scope. As a project manager I'm afraid I have to give you the same answer for a different reason: we are busy in this sprint reaching the deadline, we haven't planned it and I don't have the backup routine in the release plan as a listed functionality that I have to fulfill. As a developer I would say: yes, doable. But the alarm bells go off in my office as a hoster: first the characteristics of the restore should be clear before we could invent a suitable back-up strategy. You see, there are many ways of looking at this simple question.

Multilingual support in time? You have to be more specific to avoid disappointment in the near future. I could say Yes to you, because it's easy to install a translation module. That's my development cap. But somebody has got to do the translations as well. And that could be me in a different role, different cap: translator/configurator. If you expect 'Multilingual support' to be localized content, I would have to perform a task that I am not able to: I am not a native speaker of the foreign language that you focus at and I'm not a citizen that lives locally in that region. Whether or not I can perform the tasks in time that I am capable of doing, depends on the planning. I have to take a look at that next Thursday when I have my project management-day.

This all might seem a silly play, but it is dead serious business.

Tactics

Example: interaction design

Your tomorrow's user interaction design session with the customer will be easier if someone else (but on behalf of you) mentioned the cascade of your legal steps against him, as long as invoices remain unpaid. You could tap the customer's arm and say "please do not be to angry on him, he just doing his job. We can not blame him, can we?" The customer will respect him for his and yours professionalism. Image how hard it is to play these roles all by yourself.

  • To avoid backfire on your personal relationship with your customer you could '''introduce your real colleagues''' (individuals). Real colleagues (even if they do not know that they are your colleague) are very good to have around, you can:
    • a. blame them
    • b. praise them for their excellent work in his/hers role
  • To postpone and divert: answer the question in one or two roles right away, but then park as an agenda-item for a different role on the critical path. Example given: "Yes, technically no problem, but I have to take a look at that next Thursday when I have my project management-day."
  • Invent a diversion yourself. It's nothing to be ashamed of. In business it is done every day. Ask yourself the question "Does it sound as an excuse?" It shouldn't. It should be a ''role well played''.

Revisited

The 4 interdependent rules of earning respect and money in your work as an open source expert revisited:

  1. Deadline first, flex scope
  2. Be firm but sympathetic
  3. Sell en negotiate continuously
  4. Define roles and play them

See?!: Earning respect and money with Joomla! has nothing to do with Joomla!.

(Thanks to Froukje Frijlink who checked my English).