Playing with half of the pieces

Customers often want things because competitors have dangled them in their faces… such “discovery of customer wants” does not provide the basis for strategy; it represents a failure of strategy - Book of Certain To Win, by Chet Richards

I was always wondering what if I could play chess games only using half the pieces while doublethe moves with the guy who beats the hell out and robs like tens of points from me on FICS. Somebody has told me that if I can convince one to do so, it is almost certain that those points will find their way back. Of course I mean if. Officially if he seriously kicked my asses like that, the odds is small that he will buy this...

The point is, if you play with half of the pieces, an organisation would likely be able to double its decision making and execution speed, within the range of capability. This might also be the logic why companies like Google advocating 'lots of small companies' philosophy. WIth half of the pieces, the overhead, amount of message passengers, management internal friction and conflict of interests will certainly decrease accordingly. I have not got the scientific datum as backup, but decrease at rate of log2(n) would be my first bet. 

The other fact always amazes me is the importance of space, or empty. Without half of the pieces, you find your leftover pieces suddenly become alive. There are much less unnecessary barriers, much better chances to maximise the (attack or defence) potential of each piece. With the appreciation of speed, one can easily manuover his pieces into positions and always, whilst no surprise, secure the importan places on the board before his competitor. Whether you are planning, throwing money, getting extra hands, buying more buffer for delivery date, at the end of day, time, is really the only thing that matters, and one thing you can pretty much project everything else down to.

Reactive management

I could not remember how many times in my career life someone tells me that patience is a beauty or similar kinda crap (mind my language). I have my reasons... On the other hand, you always have people who really good at reacting.

Here is what I found out on on Friday afternoon in the building. Because of the economy, Xmas everything, things appear to wind down a lot. What is interesting to me is that if you watch closer you will see most of people, esp. those who do not really have a written down process to define every second of their daily behavior, lost their clues of what to do. ALARM!

If within a business, people do not know what they should be doing even there are road maps, meetings, corridor chats happening all the time. What went wrong? It will make more sense if we sit back and chew it a bit longer. The obvious difference leads me to remind myself of what they were like before - frenetic, absolutely frenetic! 

A normal day of their working will normally start with a few of customer complaining emails or phone calls, which will by default change their priorities either because to get a battle won will just make things look good or just because to think, plan, pre-empt about what to do is so much a hard-thinking work to do, and hey, we are all lazy nerds.  

Now we have work to do, actually, most of the time we do not really know how and what it takes to resolve these hot potatoes for dear customers, we start to raise our eyeballs and look for easy targets, internally - either to shift work with an as angry as the tone we received, or simply kick off the email war. Maybe in the end, after some stupid parties - normally will be the not much outgoing engineers - pick up the shit and sort things out, they step up to release the good news to everyone in a more or less exaggerated manner.

At the end of the day, on the way driving home, we have totally convinced ourselves that what a good day it has been - some fires have been put off by us.

Sounds familiar?

Sorry that I have been extremely sarcastic, not intentionally, as I can assure you. The point I want to make here is the situation created from reactive management.

As being said already, to estimate, plan B, pre-empt, work out risk management actions, foresee what is coming, stop issues from happening, sensible negotiation and decision making, all of these are difficult. This leaves us an easiest option - reaction. We do not need to worry about triggers; we do not worry about reasons; we do not worry about cost and consequence of resolution; we do not worry about knock-on effects. We just do it. Some people even claim that this is on the same philosophy ground as GTD (get things done). (In fact, every time if someone really tries to piss me off, he will say this.) Let's just say our species are born with a talent of finding a way out.

Anyhow, anyway, the damage of reactive management not only will cause huge managerial panic tornado easily, but also will destruct the possibility of stopping what is happening appearing again in the near future. Most dangerously, if people have already trained themselves in this mindset of reactive working habits, you will see more and more headless chicken, no matter there is a panic situation or not.

Quick turnaround time again, could be lying to us when we do not have a clear idea about what we are really dealing with - is it this defect itself, or is it something else? What I would recommend here is to give it a go with five why practice.

All about estimate

When we do not know what is gonna happen, we panic; sometimes in order not to be completely acting like elementary organisms, we guess.

In essence, we will not possibly know what is like in the future (if we do, there won't be one). A project is a means to explore certain unknown and provide solution consequently. Sometimes we succeeded, other times we lose miserably. To succeed in a project, there are hundreds of things must go right, out of which, the estimate. It might be too convenient to generalise the action we take when confronting with unknown as estimating. By doing so, however, we could possibly take a peek at where and how estimate comes from and what should we do about it and how should we use it to help us.

As being said, we cast our conjecture or theory on things we do not know for sure and then hope the dice would be hit, with bit of luck. Making an estimate is just as difficult as doing the work itself, if not much more. When there is a problem, based on analysis of the problem itself, past experience, consultancy advice, we offer our best guess. One thing people do realise and start to put more and more focus on is the approach with which the estimate is made, i.e. with the same information, how do we estimate something is probably going to happen - probability of the estimate or simply saying, treating estimate as a function of multiple random variables. Scientifically, techniques such as three-point estimate not only give us the range of estimate but also provide the confidence level associated. Although there is a fundamental flaw in such method is the assumption of independence of variables normally doesn't apply. Anyway, the estimation approach is not what I am going to talk about here, although I have already used half of the space...

Can we estimate? If positive, why do we need? If we do need, how do we use it? If we do know how to use it, how much confidence we have with it? What happen if it goes miles wrong? Do we need to update it with newest information? What does it mean by hitting the budget and endless of delay? (This question ladder should really start from another "do we need an estimate?" but as we all know that normally being answered straightaway as positive.)

Yes, I think we can and have to estimate, otherwise walking in a mist is not going to help anyone, especially those who hold they hands and await for the return of their money. Everything kicks off and depends on the esitmate, believe it or not, no matter engineering or manufacturing, purchasing or selling.

We need estimate to plan for the unknown, what should happen is that most of our plans should go from paper to bin very quickly. We need estimate to decide actions. We use estimate to de-/convince people and persuade resource and investment of interests to the good side of our belief.

The confidence level of an estimate depends on the source of the estimate as much as the approach we took to achieve it. Estimate should never be A number. You have already put everything you have on the edge and tipping your toe into a gambling game if you do. Confidence of an estimate is more important than the estimate itself, as suggested by Entropy theory. In the unfortunate but most likely situation, things didn't go as planned, (which is one of the main reasons estimate is defeated, assuming people know how to estimate.) the last thing we need is being pessimistic and throw the baby away with the bath water. Looking at whether it does fall in the possibility range you had and what is the thing really happened and triggered the domino. To find the root cause of effects would be most likely helping us get back to the game - by updating the estimate and re-do the homework, when I say homework, I mean it, on daily basis. It is also not extreme that some cases this happens on hourly basis.

Hitting the budget is always a nice thing to have. In common sense, hitting a budget mostly means management is doing a good job in planning and managing. To me, hitting a budget doesn't means you get on the train at the last minute just before the conductor closes the door. The reason why I say it is that hitting budget itself is actually funcationally irrelevant. A project is about capability and experience (in financial terms) dealing with unexpected events. A budget is made trying to measure the degree of unexpected events. It has fundamental means to play with while in nature random. Sometime if hitting budget as a target overrules logic thinking and long term view in decision making pivot, it will pay for itself in an ironical way. If you hear people complaining about the endless delay of a project compared against its original estimate, be careful, firstly you should probably ask is how the estimate gets made and when it was the last time we update the estimate. Finally, my killing question - Is there any change of scope to what we have been estimating against?

Requirement and knock out feature

Requirement is what makes things happen. It comes from needs to satisfy various living or working condition, more importantly however not intuitive, to satisfy curiosity and the hunger for invention.

In a product development cycle, everything starts from requirement. The first misconception stands out from here - things start from somewhere, so we must know where it is. We make a lot of assumptions about what we know, what people want, what we donot know, what people donot want. Yes, unfortunately, most of us start from 'we'. I think it is inevitable. This is how our brain works - when it comes across new problems, new stimuli, it first of all is to search the potential resonance. During this stage, learning and extraction following by inference happens. Any requirement analysis approaches fail to respect this are likely to be doomed.

Traditional practitioners believed this planet is the centre of the universe. On that thread, they had this fantasy either the designers are fully aware of what is required from their past lives or they are just genius, just know it. After many pioneers hit their heads on the wall, with only handful of them hit the dice, we finally decide to collect and analyse requirements. Now is the era of believers. People have this naïve belief in customers, or who would buy the thing we are gonna build. Tons of man hours, lots of support to airline economy didn't seem to pay off - this gap between what customers are satisfied at and what has been delivered is like a haunting ghost, never go away. Most of the products have to have sufficient investment to sustain till we 'finally' hit somewhere in between, or better than competition, or customers do not really have much choice. Surely there are still many very successful products coming out from the bottom of these waterfalls. Many products of this kind took long time with concentrated resource and reasonably static market environment.
Steadily, we started to realise that customer is NOT our mentor, he doesn't know what we assumed he does, hoping by doing that our development lives would be easier. As matter of fact, customer doesn't have clear view of what he is asking for, only knowing there is something alike to meet his needs. Even further, sometime customer doesn't know what he really needs. As I have explained in previous blog, he thought he wants XYZ, in fact all he wants is to achieve ABC, and he think by XYZ he could make it happen. As product development go along, the requirement creeps. This is natural since the better visibility of the product, people who look at it would have more information to feed their brain and that would either trigger a verification process, or a inventive process will be triggered to re-shape and enrich original fluffy fuzzy needs. With all these cruel realities being exposed on the floor, alongside the acceleration of market changing speed, we have to look for alternatives.

One thing also worth mentioning is, no matter what, there is always a conceptual understanding that product is delayed, in fact, what is important is managing the expectation. By the way, with second law of thermodynamics, you can not win; you can not break even; you can never get out of the game.

I don't know exactly what to do, but these are what I believe should be happening within a success,

» Customer is God. This is a correct statement only within appropriate context. Product development team should lead customer to find out about their real needs. Hence customer is not just paying for the end product, but also the learning process and experience. This would make sense for our accountants whose only interest seems to be costs and benefits (to be fair, we all do).

» There is no way anyone can envisage hence plan all out in advance. Even there is a small fraction of possibility, that would also decreased in a significantly non-linear manner to the degree of complexity and speed of change.

» What we can do is be honest with ourselves and plan out what our eyes can see in front of us. In the same time, knowing how to use the back of envelope estimate as a guidance rather than a full time project manager's job to cook a good-looking chart.

» Commitment is a serious business. Without a feeling of fixture doesn't mean no commitment needs to be made. Be aware that every step you make in product development, every deliverable coming out from the circular pipe would have directional effects on what is going to happen in the next ones.

» Break the cost, time, quality triangle. Define the affordable time and cost then see what we can deliver.

Knock out features are those hit the invention button, not only because they have been implemented by genius who is capable of peeking the wonderful requirement myth above, but also the designer is consciously delivering altruism - probing the user's curiosity, allowing them to explore more with this product rather than less. The reason that I say this is I believe every product, every new gadget in a way limited your option, you view of the world while it offers you certain ability from the vehicle. When we say a product is intuitive, what we are really saying is the product doesn't limit the way we look,feel and deal with things by what it offers. Just like dad used to say, "you can go ski, as long as you put on those clumsy clothes" or "you can use a blackberry, as long as you can live with tiny keyboard hurt your hands".

Handson or handsoff

This comes up from a conversation with Jonanthan. Although it is possibly one of the first questions I have to consider when first transition from engineer to technical management. Bottom line is I don't believe effective management could be achieved without solid understanding of technical difficulties and product itself. Sounds like an easy call?

PMI tells us, 90% of project management is about communication. What PMI or most of the management books did not tell us is, both management and engineering are certain types of data processing. Engineers process data via either physical transformation (mechanical gear transmission design, servo control, encoder sensor feedback analysis), electronic signal process (signal generation, data sampling, signal analysis and feature extraction, spectrum analysis and estimation) or logic interpretation (logic circuit design, time-based state machine, bus-based data propagation and transmission, protocol interfacing, optimisation algorithm, pattern extraction and construction, data re-organisation, logic mapping and pattern classification).
What managers do? Not being funny, unfortunately, this question gets asked often by engineers! Many managers choose to hide behind of their roles to 'follow the process, do the job' rather than really thinking about what should be the management responsibility, focus, and what gets things done.
In my opinion, management is also about processing data - processing data collected from 'sensors', data analysis from systems (could be bad data, or even to extract useful information from noisy data samples), data feature extraction and inference, data propagation and transmission, protocol interfacing, pattern recognition and estimation, most importantly data generation. I will break these down:

• Data collection - Managers are responsible to put the right and sufficient information together, either product issues, engineering design constraints, requirement specification, cost etc. The method to collect the data has to be scientific. Unsound approach will invalidate the data you sampled, pretty much the same way Jury will look at your case.
• Data analysis - Managers are also responsible to analyse the data collected. To know what we are looking for, and what we can look for, what pre-processing is needed before data really makes sense to us, do NOT jump to conclusion before data is actually understandable. Gut feeling is irrelevant.
• Feature extraction and inference - Now managers with cozy office will need to do some homework. To extract the features embedded in pre-processed data is not an easy job. You have to be sharp enough to not be buried by trillions of bytes flushing in front of your eyes every milli-second (slightly exaggeration here...).
• Pattern recognition and estimation - To recognise patterns certainly needs experience, although in lots of movies directors trying to convince us it is all about gift.
• Data propagation and transmission - Interestingly, this part is what most manager do well, exceptionally well, to the point in many organisations, there are many managers they believe, or at least it appears to be, that the sole purpose to have management role is to be an information passenger. In fact, to make sure the data is propagated to the right receiver and that only needs a lot of skills. You can't use broadcast everytime without getting in danger of damaging enviroment; multicasting needs policy support; unicast incur transmission overhead.
• Protocol interfacing - Almost every product, to be a piece of usable item in real world, it has to interface with other parties, like it or not. Data transmission, or in a more explicit term - communication, must follow certain protocol to be able to achieve efficiency, security, stability and robustness, extendibility and integratability (oops, sorry, too many abilities...).
• Data generation - Most importantly, as much as a general rule, to produce data, is what really matters. Without this, there is no need for processing, and bluntly, no need for management. Management is about decision, is about getting through all the steps and being able to, and willing to, make the decision about whatever it is about.

Without too much efforts (actually, a bit, admittedly), I am convinced that whether you are doing engineering work or management work, you are processing the data either way. The point is the real difference in handson and handsoff is not what work you do, is about how you do it. Handson is about you get into the details about what you do, being realistic and objective about the true identity of the data, do not randomly or arbitrately interpret the data samples, being scientific about the embedded patterns and using which to make prediction or logic inference. Being handson is about choosing right methods and attitude to process the data, to confront with real world issues without unsound assumptions, being honest about situation and problems, and a little bit of faith in problem solving (this is in fact belief in finding resonance with the underneath patterns embedded in the universe, I am a great believer that we donot create patterns, we find and learn them).

Although in reality, handsoff engineering might sound a pretty crapy idea and one would get caught easily if he keeps his handsoff while he was supposed to deliver 5000 lines of code a week - let's just say being a manager, keeping handsoff will be less vulnerable in the short term compared with engineering work. However, to an organisation, handsoff management will have much more detrimental long term effects.

Backlog and throw your project plan away

-- reflection on Mike Cottmeyer's Agile presentation

Assumption on requirement is evil.

Backlog: As a ___, I would like to do ___ to achieve ___. The reason I highlighted this note is this is so damn true. Once I had a complaint from a customer in Italy threatening to kick our half million pounds system out - he is not satisfied. But why? He said he can't do XYZ. Okay, everybody in the loop starts to panic that why our system can't do XYZ, to do that, how long they have to wait for etc etc. Then I called him up and say hey, can I just ask one question, why would you want to do XYZ with our system? He said, "because I need to be able to have this ABC effect." I don't have to complete the rest of the story I guess.

Reverse the triangle - define time, cost first rather than scope.

Release planning is to follow the defined time, affordable cost and see what we can achieve from the backlogs (with MoSCoW applied split in backlog sets).

Short cycle time to be fixed first and then we can look at what could be done for that time. The planning efforts should not be focused on the nice good-looking Gannt chart, but on the defined Releases->Sprints, with the negotiation of backlogs in between.

SOA

"Simple, clear, purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior." -- Dee Hock

Project management legend

Every morning you woke up and google for project management you will find new books, blogs, podcast talking about new thinking or methodology. I have spent 45 minutes in the morning on a train to a place where I burn myself to full extent everyday. I am loving it. Not because any project management legend reveal itself in my daily work, on the contrary, none of them has.

Here is a suggestion, go to your bookshelf and your harddrive, pull out all the content which are project management related, put them in those big PC box you took for free from office. The idea is, let's see what would happen if you don't refer to them for 3 months.

I never believe, you can adopt a project management methodology and make it work. It doesn't work like that, the sequence is wrong. You deal with mess for a while; because you are a hitchhiker in nature so you are lucky that you have not got bogged down by the negative experience; you decide that changes might sound like a good idea; you think hard about which are the areas should be improved, most of the times, those are the areas are most sensitive in an organisation; you work out what is wrong, and what is the result should be if thing doesn't go wrong; you maybe don't know about the fancy buzz words used in various ridiculously expensive management training course, but again, you are lucky enough to know some common senses - what stops things working is bad, what makes things tick is good; you then put those small pieces which made things tick from your past lives and those you stole from greater minds; now you have weapons to deal with the devil which dragged you down; you exercise them, some are still tasty, some gone out of date already, anyway, you end up with bunch of practice which proved to tick the boxes in where you are... This is for real, real management life.

So, why we choose to escape from the problems and wish that someone else who is NOT in your position has already figured this all out FOR you? There is NO free lunch. No one has come along from exactly the same path. If you are a project manager in an organisation, you should consider yourself unique, although wiser did say that you can't believe how much effort people has thrown just try to be normal. The problem is unique, the opportunity is unique. No one has resolved this before, there is no place to hide for you.

A good project manager don't believe in legend or myth. He has faith in humanity. We know what went wrong, as long as you keep a fresh eye in the morning; we also know how to deal with them, as long as we have enough courage not to search for legends.

Now, it doesn't mean that we could not summarise typical situations a project manager could end up with.

A. Endless project

B. Fragmental project team

C. No focus, no confidence, no commitment, if there are identifiable stakeholders

D. Faultlessly wrong design

E. Time/Money/Quality pick-two game

F. Now really, we don't know what we are building, we aren't even know who is going to buy the stuff

G. For the name of heaven, there is no safe island, all you have is risk, how could you manage

H. On top of all, let's play politics

A good project manager has fairy good idea of what kinda troubles he has got himself into within very short time. Sadly, many of us make assumptions way too easily that we could rely on our shiny experience to kill the bugs. Unfortunately, history proves us wrong, all the time actually. Experience tells us what problems we might need to confront, but it doesn't offer us a silver bullet. Simply becase the solution of the problem is so unique to the subtly different environment you are in. Let's just say, give up on the reference thing, be creative, no one is gonna blame you that you didn't quote the Greece as long as you get people out of trouble.