photo ? 2007 Powderruns | more info (via: Wylio)

First projects started in May.

We don’t need to do annual reports just yet, but here are some highlights:

• We started with a team of two, finished the year with a team of 7
• We worked for 8 different clients during the year
• We derived 75% of revenues from projects for new clients
• 70% of revenues was generated in most challenging Financial Services sector
• We completed our first project abroad

Next year… is going to be exciting!

Therefore it might be a shame to admit that it was only recently that I became aware of his works, nevertheless, I wanted to share appreciation of his identity document for Steve Jobs’ NEXT:

On the webpage, you need to scroll down to “identity presentations” section. Reading from photos is not comfortable but doable, especially if you are on a mac and can zoom easily.

One might find his approach to design problems rather intellectual if not pedantic, with all the detailed discussion of why this font and not another, why in italics and why in this color, but I find it quite fascinating, personally.

In fact, I found my way to this document passing from Steve Job’s record of his relationship with Rand:

Note the fragment when Jobs describes Rand’s way of working with his clients:

I asked him if he would come up with a few options. And he said, “No, I will solve your problem for you, and you will pay me. And you don’t have to use the solution – if you want options, go talk to other people. But I’ll solve your problem for you the best way I know how, and you use it or not, that’s up to you – you’re the client – but you pay me.”

This reminds me, by the way, of a common dilemma in consulting of whether we solve problems for the client or with the client.

But to finish the episode with Steve Jobs and Rand, here is the account of how the cooperation started:

Jobs had always had an eye for good design. He was especially taken with the logos of ABC, IBM, UPS, and Westinghouse, all of which were created by Yale professor Paul Rand. Rand offered to create NeXT’s logo for $100,000, but only if IBM consented.

This was an outrageous price, many times more than what Rand had charged IBM for its now-iconic logo. Two months later, Rand sent Jobs a copy of the logo and a brochure explaining every detail. For the sake of a more interesting design, Rand even renamed the company NeXT, saying the ‘e’ stood for education. The new logo (and the name behind it) lent prestige and clout to a company without customers or a product.

Details include registering company (in fact two companies), selecting accounting firm, developing company’s brand and identity.

We are trying to be quite innovative and perfectionist in each of these, except for maybe the accounting.

Everyone left for skiing and all, but we are managing these details and it’s actually kind of fun.

Ogito, on the other hand, is closed for the time when I have time for another experiment.

I guess I should be more concerned about investing lots of time and then switching to something else without obvious return, but I’m really not. I guess I like experiments.

Jokes about global warming are probably tired already, but the fact is, I can hardly recall a winter like that. I mean the situation when you lost track of how long the snow has been around – it’s been so long.

I have a feeling that a proper winter spells a very good year. I don’t have anything tangible to back up this expectation, except perhaps how the frost is killing all the wormies etc.

In any case, this year for us is about pumping all the startuping experience into consulting, which is something we know best, and we have lots of ideas how to make it even better, therefore we are quite excited about it.

This post is due to the fact that I feel like writing rather than reading on this lazy Saturday.

Trying to make it more respectable.

In the last couple of years I tested relation with consulting industry from three different angles: as an employee of a large international company, as a freelancer, and now as an operator of a stand-alone consulting practice. Each has its set of pros and cons.

As an employee you get comfort, stability and benefits, and initially you can learn a lot. However, you don’t have any control over your life, you are not rewarded for managing projects unless you are a manager, and you are not rewarded for selling projects unless you are a partner (and I love selling projects).

As a freelancer, you get control over your time, you have incentives to sell and most likely you earn more money. You don’t have direct responsibility for projects, so I was thinking you would be under less stress, too. However, I discovered that watching some people managing projects and having little influence over them is more stressful than having the whole responsibility for the project myself.

Which brings me to third mode of operation, negotiating and selling projects oneself. It’s a hell of a fun so far. It’s like having a startup, but in area when you have the most expertise, so it’s like a ride downhill. You make all decisions. You can invest in research and development to improve the way things are delivered. Or hire people you want to work with.

Sure, it might be just a honeymoon period, but I’m enjoying it enormously.

Boies Schiller is a legal firm, so how can it be interesting?

What is interesting is that they are very successful due to their willingness to use flexible fee structures. For example, they agree with the client to cap his legal expenses, or base their remuneration mostly on success fees.

On the other hand in consulting success fees are also used sometimes (restructuring jobs, which can be quantified with relative ease), but not very often, so I’m thinking if finding some areas in which risk could be shared with the client would not reveal interesting opportunities.

Why tedious? Well, one reason is that process documentation tends to have large volume, while efforts required to produce it are mostly not automated.

I was wondering if there is any simple way to streamline this kind of jobs, aside from hiring more analysts or investing in a some BPM software package, which would probably be an overkill for most of the projects I did.

Making any amendments to the processes is especially pita, due to all the custom diagrams interlinked with detailed textual content.

(that is if you use diagrams + text – sometimes just slides are used, especially for high-level documents – I think text is much more flexible if you need to accommodate more information)

While in fact, amending the design based on remarks from business users is the core of process-related projects.

Process-related projects shouldn’t be such a chore – if you take away all the time wasted with Microsoft Office, these projects allow to get the best idea of how the business really works.

Looking back, projects involving deep understanding of processes provide most powerful references today.

The kind of customized process work that is done during relatively short strategy project shouldn’t be mistaken with implementing whole “process-driven” approaches in the company, for which elaborate business process management IT solutions exist.

The idea is to store process designs in central repository, where they can be easily versioned, accessed by large groups of employees (which can be assigned different access rights), monitored, and modified.

Truth is – maybe it’s because it’s Eastern Europe and we are backwards – I never saw any of these system in real world use at any of the clients. Perhaps they are more popular in production company than the financial sector. I remember one Russian client mentioning before the project started that they had one, and that deliverables (processes to a large extent) would eventually have to be integrated in it somehow, but it was the only time the topic emerged.

I think there are plenty of good reasons for such solutions to have difficulties in real life adoption.

Enabling new users (like external consultants) to access the system requires at least creating new logins, in worst case it might require to buy additional licenses. Hardly easier that just emailing process documents.

People are used to work with Word or Powerpoint documents, but might need time to master unfamiliar interface of the process application.

Even though usually it should be possible to export process information in format like PDF, it might not be possible to export in format that is editable, so ad-hoc participants can contribute remarks.

The reason are many and truly converting organization to be managed around a consistent BPM system must be a daunting task. And partial implementations often leave orphaned systems that are not used.

For now, I was rather thinking if there was any way to improve the way stand-alone process documentation is created, rather than an end-to-end system.

Starting with drawing process flow diagrams, for example. Which, for now, may take place in Visio, or, since many clients may not have Visio, in Powerpoint.

I started to look around if there are any online services allowing to create process diagrams and I stumbled upon LovelyCharts, which are really lovely.

The interface is friendly and simplistic (app is created in Adobe Air, for the record).

Basic process components are all there (more than I use in fact, I believe processes are mostly tools to communicate and adding symbols that require legend to understand doesn’t facilitate communication).

You can just drag components and the app takes care of aligning the arrows etc., unlike Microsoft Office.

Unfortunately, one key feature is missing as far as actual process documentation is concerned, which is ability to create swimlanes diagrams, to illustrate roles of many actors.

Also, currently LC can export diagrams to images or PDF, but it would be optimal if it could export to powerpoint files, so that it can be delivered to the client in editable format.

Having a tool like LC to quickly visualize processes and amend them effortlessly would be just first step.

Diagrams are accompanied by text documents detailing each step (at least the documentation style I use), and having diagram changed requires to manually adjust all the detailed descriptions.

I could image a higher level application interfacing with visualization tool like LC, allowing to automatically number the steps, add description or technical details to each one, and export both diagrams and text into one word document with one click.

Just an idea. Note that I look at it from strategy consulting perspective (hence the emphasis on stand-alone process documentation, design-and-deliver), and I fully expect, for example, ISO consultants to have possibly quite different needs.

I saw two obvious solutions: find an investor or do freelance consulting.

Finding investors is something I don’t have much experience in, and moreover the timing is not too good, crisis and what not. I was lucky to have some friends declare to invest if necessary (which was not necessary yet), but as far as investment funds are concerned, I talked to just two of them and that was it.

Consulting, on the other hand, is a proven and quite manageable (I hope) revenue engine. Having commercial activity in form of consulting, in which I have experience, would allow to finance all the other activities, in which I don’t have so much experience just yet.

A week ago on Monday I woke up to see an email which could go as an rfp, and voila, till the evening my first freelance project was sold (why bother to execute your strategy if you can just let it happen).

The client: an investment fund. Ironic.

Actually it’s not really my first freelance consulting, but I’m taking into account just post-corporate period.

We managed to cover quite a lot of ground in less than a week, and both sides are happy. Three sides even, since I don’t really like to work alone.

Maybe more will come. Will see. Need some business card eventually, if more are supposed to come.

It’s was a nice feeling.

But still no luck with the backpack, which is missing after the Cuban adventure… I’m losing hope of seeing it again.

But this article proved I was wrong:

In every project, there are issues that that frighten the bejesus out of the team. They are so frightening that no one wants to talk about them publicly. The schedule might be impossible. There might be the lurking suspicion that Management does not believe in the project. More commonly, there is a major technical flaw that no one is handling.

The article relates to game development, but the issue is relevant for any other project. The urge to keep sensitive issues under the carpet is familiar enough.

Here are some steps I recall from the latest consulting project that helped in management of the “scary” stuff:

• Carefully store and process remarks sent by the client (there is good chance that sensitive issues are among them): store all remarks in one document, color-code them to distinguish difficult ones, dedicate a meeting with a client for walking through the remarks to ensure that they are understood properly and agree the solution
• When sensitive issue is identified, create dedicated approach to solve/mitigate it: brainstorm possible solutions, create issue tree to structure the thinking, identify constraints related to the issue (e.g. define most pessimistic scenario and start from there)
• Dedicate resources to follow the agreed approach to resolve/mitigate the issue

Some issues may really seem scary, but it turned out that solving them (or at least addressing them and mitigating related risk as far as it was possible) raised client’s confidence in the overall direction and justified all the effort that went into sorting them out.