| What is the COMMERCE-SAVVY Blog? | |
 | It's for anyone in a technical role who is frustrated or keen to develop their career and personal skills and abilities in business leadership, management and commercialism. |
| The COMMERCE-SAVVY.COM Blog is a journal of short articles or snippets of information I've gathered from across the web and from my experiences with working with talented people. |
|
Take a look at the information resources and services offered by COMMERCE-SAVVY.COM by visiting http://www.commerce-savvy.com |
|
I welcome and encourage your feedback on this blog, good and bad. I want to create a valuable resource for our professional community. simon@commerce-savvy.com |
Technical professions require precision in language. We can’t express computer program code in slang, as much as we can’t express an insurance illustration without being exact. So in our profession, you’d expect all articulation and use of language to be unambiguous and precise, wouldn’t you?
Well research has shown that technical professionals can still lack precision in language outside of pure technical expression. For example, a developer might report “I’ve fixed most of the bugs” or “the majority of code is ready.” I think for most conversations this is OK, as being precise might mean very lengthy conversations! It’s unacceptable in management reports, particularly between supplier and customer.
In today’s world of international outsourcing and flatter management structures, precision of language is growing in importance. Workers are being held to account much more than before, and this will continue. The problem becomes more acute with language barriers and cultural differences.
So I wrote this article titled ‘tuning into language’ to firstly highlight the issue, and secondly to suggest a way forward. The key to avoiding miscommunication is in the art of asking questions, not necessarily bloating reports.
I think it is acceptable, for the benefit of efficient communication, to allow vague statements to be made. Most of the time, people involved in a conversation have enough content and context to know what’s being said. When a communication is more formal, such as an RFP document or project dashboard, there is no escaping the need to lay out all the pertinent information for the communication to be credible. But when it’s a conversation, I think the onus is on the receiver of the message to ‘tune-in’ to the language and ask for more precision. Sometimes (and lets be honest) one might say something vague because we don’t know what we’re talking about deep enough, or are trying to deceive the other person. It happens, particularly with people from other cultures where losing face is a major sin. We shouldn’t be allowed to get away with it! For example, a developer may say "most of the bugs have been fixed", the receiver may ask "how many have been fixed and how many remain?" or perhaps she might ask "what about the remainder that hasn’t, when will those be fixed?" Further drilling will reveal the underlying data and truth.
This may not look like rocket science, and you’d be right. But I think vague statements often go by unchallenged. I believe that it’s our responsibility that if we partake in a conversation, we tune in and make the most of it by drilling down. This will create the best chance of optimizing the conversation, and from a cynical viewpoint prevent a skilful hoodwink.
This subject was suggested by Juan Cortez in London (thanks Juan)
I frequently see and hear about how organizations struggle with the planning of programmes or large scale projects, as is often the case nowadays, they involve the integration of many partners, business units, mavericks, doubters and in summary complexity. The complexity, at first, creates chaos which manifests itself as overwhelming dependencies and uncertain delivery dates. This can be a headache. A big headache.
What happens often is that there is a long malaise of inactivity and spinning of wheels without tangible progress (sometimes called Planning Paralysis). Execs and senior managers get impatient and attempt to intervene by de-scoping deliverables, changing structures or setting hares running in the wrong direction. It’s their prerogative and understandable.
But it needn’t be that way, if you understand how a chaotic situation like this can be controlled by allowing uncertainty in, and ‘banking’ the certainties. Let me explain.
The world isn’t perfect, so therefore information is not perfect. Projects start with assumptions and beliefs, and a planning process starts from there. Often these assumptions on scope, resource availability, buy-in and budget are flawed (as time tells). It's safe to say that the project starts from an optimistic point of view. However it is often the tendency of project planners to try to fix a plan of a long-term project in minute detail in order to get to (what is often an arbitrarily set) target completion date. As information flows back into the planning process, the dependencies are mapped onto a ‘critical path’ - the date can’t be met. Panic ensues. Chaos reigns.
But what if we ‘banked’ the certainties? I.e. if we were confident (say 90% plus) of the next three months of a twelve month project but only 50% certain of the following nine months, why not say that? Why not let chaos be controlled after the first three months with that caveat? As a project planner, if you can give certainty for 90 days ahead, that is a positive statement. Besides even if you could give certainty now for the whole twelve months, something will come later to disrupt it. Guaranteed. By applying a rolling plan of certainty, you can get the project moving and starting banking the resulting deliveries. Allowing chaos room later (and it will likely be always later, not the next three months) then you have the project under management.
Of course, the prevailing period of chaos must have a project framework of resources, deliverables and delivery dates. This approach won’t work if you’re blind to the full scope of the project. But the lynchpin of this approach is establishing an active and pro-active planning mechanism for three months ahead.
In highly risk-averse environments, this approach may not be considered acceptable. I’ve found this strange as there is always a balance of risk of doing something and not doing something. Without this approach, I have found, the project takes a long time to gain momentum and traction on deliveries. This initial period is almost always unplanned.
Final point is to address the above point. In highly risk-averse environments, my recommendation is to plan on a lengthy period of feasibility and dependency analysis upfront, where all questions are answered, plugged into the plan and further iterations performed. However, the appetite of risk must be shared right up to Exec level for this to work, or chaos will take hold as Execs’ perform their ‘management interventions’.
This subject was suggested by Brian Jones in New York City (thanks Brian)
'Governance' is a term that is becoming more and more popular in today's business. Governance, in essence, is the process of policing an organization internally, making sure standards and policies are adhered to, budgets are kept and that decisions are rational and appropriately transparent. Governance is there to ensure your organization complies with Sarbanes-Oxley, should it be required to. In the eyes of many people, governance stalls progress, stifles intuition and innovation, and is entirely bureaucratic. But which is it? Well it can be both, depending on how it is applied and perceived by those being 'governed'.
As technical professionals, it's our job to make decisions and implement technology, whether it be IT, product rules, calculate risk, etc. To do that job, we need skills, experience and judgment. We apply them at our discretion. But how do you know you apply those things in line with policy, regulation, risk appetite and without bias, using all the facts? Governance functions are there to help you know, and to also report this to senior Execs. Often their work appears as dashboards for Execs, where each 'measure' (mostly an arbitrary scale of compliance) is scored, often as a RAG (Red: Bad, Amber: Not bad, but not good, Green: Good)
The irritation of governance, I have concluded, is that in order to gain a view on each measure, a bunch of questions need to be answered, forms filled, meetings held and time committed. But moreover it generally requires the governance body to have some, equal or more knowledge in the subject areas of those being governed and how that subject fits into the big picture of an organization. The esoteric nature of technical subjects can mean this is very difficult to actually achieve. This can result in risks and issues being misreported, incorrectly measured or badly articulated up towards Execs. Then you have to spend time unravelling it and getting the story straight. The sum total can be a lot of wasted energy and time. Even worse is when technical projects and initiatives are discarded at the thought stage due to concerns about getting it by the long arm of the internal law! Innovation suffers. It can create a huge overhead at great cost.
So is this is an attack on governance? Actually no. Not at all. In fact I think governance is essential for a modern organization to tick. Governance can prevent a business making a stupid decision. It can retain corporate memory so that the organization knows why a decision was made and what compromise was accepted. Governance can give an organization's Exec valuable information to make rational decisions from (Execs can tend to act on intuition alone!) But governance has to be applied effectively and appropriately. You won't have control of that, well not at least all the time. But as a technical professional, you can have influence over the process, by building a trusting and open relationship with the governors, building credibility. By working closely with a governor such as Internal Audit, you can use policy to guide decisions, preventing further rework and rectification. It will also help you build in some latitude with the body so that you can have influence of what is 'governed' closely, or not. In past appointments I have made the first move with Internal Audit by inviting them in, for example, to team meetings and giving them an open slot. I've also instigated the construction of a Risk Register (where risks under my control are documented and actively managed). The result of this was a growing relationship based on trust. Governance should not be feared, but it should be controlled and influenced appropriately and with integrity.
I can't stress this enough; building a strong relationship with governance will give you an edge. Governance isn't a pain in the ass if you don't make it that way.
Are you bored or overwhelmed by governance? Let me know: simon@commerce-savvy.com
You might consider this subject more general than technical matters, and you’d be right. Although actually I am writing about the opening and closure of meetings about technical subjects, whether they be about discussions, reviews, decision making or methodology. If as a technical professional and a host of meetings you’ve felt that your meetings haven’t had the right spark of energy, or actually resulted in anything but a room full of hot air, then read on.
The thing is having observed meetings held by technical folk for many years, I’ve noticed a pattern of weakness that I think can be easily overcome. There are two aspects of this pattern:
Now I’ve titled this as the ‘art’ of opening and closing meeting for one reason and that is we should always remember that the members of a meeting are human beings with personal lives, financial worries, family matters, dreams, aspirations and possibly back-pain. The reference to ‘art’ is that there isn’t generally a formula for opening a meeting that allows the humanity in for a while. But there are simple things that can humanize a meeting, break the ice and set the meeting up nicely.
Such things may be celebrating a success by the group or by an individual, or sharing some other positive news. It could be as simple as talking about the weather. Whatever your choice of subject, talk about something positive that everyone can engage in. Get faces smiling and a few laughs in before the technical subjects flood in. What you will find is:
So I’m going to skip now to the end of the meeting, during which you may have taken notes or had someone record minutes. The ‘content’ of the meeting is over, but the meeting itself is not.
You should always end the meeting by summarizing the content of the meeting, in most cases expressed as the agreed actions with owners. If you hadn’t done so before, an expectation of the timeframe for the action should be discussed. This becomes your indelible record of commitment, and should be published to the group after the meeting. It’s also crucial at this point that if you suspect any action isn’t clear, or hasn’t been understood properly, that this is called out. A way of confirming the understanding is to ask what the output of the action is, such as a paper, a decision, etc. Whatever it takes to be satisfied that the next steps have the best chance of success, you should take it!
Want an alternative view on how best to hold meetings? Then I recommend the following two books:
