First of all, never, ever look for third party tools will magically implement your core, proprietary processes. If your processes differentiate you from your competition, then by definition you will not find them boxed up in a software package. You want an AR system, go buy one, as AR will no give competitive advantages as it just needs to function appropriately so you collect the bills.

The same holds true for your core capabilities. Outsourcing programming activities to third parties can be like paying someone to train for a marathon for you. Unless you have involvement and control of the development cycle you will never have a working product worth supporting. Sure, you can find Open Source products that will perform functions for you but you still have to put them through a test cycle, and the same holds true for third parties. You have to test them as rigorously as well. In the end the success of this test will depend on your specifications and ability to communicate to potential partners in development.

This brings us to the subject of testability and verification. If you are going to have a development outfit produce something, how will you inspect it? What if they are not on site, how do you inspect then? Should you be on a mission critical application you need to sit in on the team meetings everyday you can get a feel for what is driving the productivity of the project. Many firms don’t like this, as it is disruptive to their processes but that’s their issue to resolve. Maybe if they are too ridged to accommodate that they may not be the right development partner for you. Finally, you should insist on the test team conducting their tests at your facility, with you at each step. Again your goal is to get a feel for the issues that arise – maybe they relate back to the arguments that you were privy to earlier during the development phase.

If you come through this with a third party and produce a successful launch then you can consider relaxing some of the oversight, but not by much. Proximity only breeds a higher degree of honesty. It should be easier for you to get a feel for timing of solution delivery as you will have worked with team members and be familiar with strengths and weaknesses. You may be in a position to request that a certain individual work on a project because of a good history of delivery. Who knows, maybe that person even practices ActiveEngine methods.

What is Sensei saying? With a title like that you should go to the next blog. NOOO!! This is a challenge to train your mind to use an ActiveEngine method. Why? Because you’ll find the productivity you’ll experience will be liberating. The ActiveEngine method is to state your objectives on 1 piece of paper, in English, with no acronyms, and read it everyday. It may seem underwhelming and obvious but it is rarely done. In the technical fields it is rarer, as quick and sharp thinks many times lack the discipline to keep things clear. So before we run out of paragraphs we better introduce the concepts otherwise Sensei won’t pull this stunt off. The big five are: streamlined communications, the theory of necessary and sufficient, the 80/20 rule, ignorance, and Cesar’s theory of the calm submissive mind.

Streamlining your communication is simple: turn off email except for two times a day, write emails less, and refer people back to your goals and elucidate your objectives and tactics in context of those goals. Probably you could use your one pager. Copy and paste works great with email, so you have to type less. For team projects publish the objectives EVERYWHERE. And, do not use acronyms. English.

The next three concepts – the theory of necessary and sufficient, the 80 / 20 rule, and ignorance – are related. Necessary and sufficient are those things that meet the conditions, only those conditions set forth in your objectives. the corollary questions are: Do you need it, and does it do what it should? A little wisdom will be needed if you are concerned with building software, as sometimes necessary and sufficient can paint you into a corner. But in many cases it will keep you out of the valley of constant re-working your solutions. The 80/20 rule, or Pareto’s Law, is the concept that only approximately 20% of any activity will produce 80% of your results. In other words, most of what we expend our energy on is not aligned with the productive acts that give you results. Both theories are enforced with that sheet of paper we talked about, as the activities you do should only be aligned with those goals. The one pager is the reference sheet for the ground rules regulating what you are working on, and in some cases how you do it. A state of “Ignorance” becomes applicable in that purposefully ignoring those actions, distractions, and musings that do not fall in the 20% category is a strength. If it ain’t on the sheet of paper, it don’t matter.

Finally, a calm submissive state of mind stems from discipline and consistency. Cesar Millan tames unruly dogs by walking them, everyday. This routine establishes order amongst the pack, and readies the dog to be formally trained. So, you need to”walk the project” and review those objectives, get the team members to recite them in their sleep.The benefits to these 5 concepts are clarity of thought, focused energy, and resolve. Imagine this: you bump into the CFO in lobby, and when asked what you are working on and your progress, you’ll have already practiced the answer with the clear, succinctly selected words your whole team has using to describe the project. They will also echo your summary. Your streamlined approach will instill confidence when your superior does not struggle to understand what it is you are describing. You’ll remain on task with the resolve to attain your goals. This will help you keep your job and advance. As promised, Sensei delivered the message: 5-4-3-2-1 you do it too.

As a corollary to the post Ego is the Mind Killer, a practitioner of ActiveEngine principles will always seek the basics and routine to liberate the mind. Constraints are the best way to innovate, to turn the puzzle upside down, read the paragraph from end to beginning. Constraints force you to make a decision and take action, innovate further why attaining your goal.

Your skill built from years of hard work, trials of failure and above all the alacrity to achieve through struggle will shape your mind to solve problems more quickly. Having the discipline to face criticism when it comes head on tempers your talents like fine steal. Forgery of steel is violent, harsh, but what is born from pounding and fire endures.

Just because you solve something once, doesn’t mean you can not optimize later. Analysis paralysis delays validation of your skills. Fail early, regroup, then win. Maybe that doesn’t happen until the fifth time. Who cares – you’re on deadline so be assured you will be around to try again. When you deliver you actually get the freedom to experiment later on.

Years ago when ActiveEngine Sensei attended Kenshu, he was struck by the fact that some of the most humble of the akidoka were the seniors. Every class the students were exposed to shi-doho style of teaching, when O-Sensei would select a technique, one from among thousands, and then select a student at random to demonstrate in front of the class. After demonstrating the technique, the other students would ask questions. Many times these questions forced you to realize how little you knew, while on other occasions the senior’s questions were merely a convention to tell you that you had made a mistake.

But this was not the most brutal part. After the question and answer session finished, O-Sensei would then deliver his critique, which could cover any foible, any weird movement, tone of voice that occurred in your delivery. This was difficult to hear. Some times a senior would be selected to demonstrate the most basic technique, then receive unending criticism.

But one senior explained to ActiveEngine Sensei, who was left discouraged and afraid after many stinging reviews, that this was the best gift you could get from the seniors and O-Sensei.

“What an opportunity. You have people who think enough of you to ask questions, point out errors and give things for you to work on. The harsh style is to train your ego, because your ego just gets in the way.”

Developers need to be shown things – they’re the “Show me guys”, but many fall into the “Show-me-no-don’t-show-me” syndrome where their egos cloud their thoughts. For those of you who want to get to the next level of performance and build your own ActiveEngine, check your ego barometer every now and then. This way you will open yourself to learning a lot more.

“The greatest challenge to any thinker is stating the problem in a way that will allow a solution.” – Bertrand Russell

If you head over to ProjectManagement411.com Bob has started a conversation focused on how a Project Management Office (PMO) can assist with describing your domain of problems. This got me thinking about how difficult it can be to clearly define the goals of a domain in terms that all teams involved can understand.

I went to the archives at DotNetRocks, and listened to the Eric Evans interview concerning Domain Driven Design and Domain Specific Languages. Right off the bat Eric said, and I am paraphrasing, “Developers usually bring the the mindset to the table of ‘how can I use web services or design patterns to solve this problem for my customer’. What is needed is better understanding of the customer’s problems.”

If you think about what he is saying, then Domain Specific Languages can only be produced after the development team are experts in the business unit’s subject matter. Taken further, a Domain Specific Language, or even the size of the domain that the developers are attempting to model may need to be reduced drastically, as the customers business processes may not be mature enough for such finite detail. And consider the other end of the spectrum where the problem domain is very mature, and the development team is attempting to recreate the wheel just so that the problems fits the solution paradigm.

A practitioner of ActiveEngine will chose the course that aligns the interest of the clients first. You must have mastery of the client’s subject matter FIRST, and be conversant in their language before you work your magic. Remember, if they don’t understand you, they may pay much attention.

Like this:

Coders love to improve things and sometimes can’t understand why a company would want to enhance or replace a “bad” process. Here’s some advice on being impatient with lack of change: don’t be impatient with a lack of change. When you rail against process owners they’ll think you think their stupid; when you flail at convincing someone of their inept ways and how extensiblity will save them money, you’ll stutter, sound like a techie idiot, and will be ignored.

There are three levels to decision making that need to overcome. They are the intellectual level, the physical level, and the emotional level, and guess which one is the deciding factor? Emotional. And this level is the most difficult to overcome.

Programmers don’t understand this as their emotions play out in different ways where passion is derived from creating elegant code. But this prevents them from moving the decision makers appropiately. If you state your case and point to real samples of timing, defects, and impact to other dependencies you may have a chance of convincing someone to make the changes you want. Use English to explain yourself and your arguments, and forget all the buzzwords you read on the blogs. Nobody important who signs your check cares about that jargon.
They do care about money. If you lose the intellectual battle, submit you case, and be ready to step in when they’ve been hit with a huge bill. Nothing crystallizes thoughts more than “I just lost out on an opportunity and we could have saved money.” Be ready to move then. The situation is making the argument for you and you’ll have to do less work as your arguments, if expressed appropriately, be even clearer.

Add the Art of Letting Bad Things Happen to your ActiveEngine toolkit. This new found patience will win you more in the long run.