Friday, May 28, 2010
If you are lucky enough to have responsibility for the totality or even a large portion of a transformation project, you will be called upon to make a number of decisions on an as-you-go basis. Mike Shanahan, former coach of the Denver Broncos, is reputed to have arrived at each game armed with a pre-scripted number of plays. But even he needed to adjust to the demands of the game when unforeseen circumstances, such as interceptions, fumbles or holding penalties, altered his original plan. Likewise, a strong planning stage and clear definition of the architecture, tenets and standards can facilitate the decision-making for a transformation project. oweh However, in the end you are bound to encounter situations that demand impromptu judgment calls.
Being a good leader is often about making the correct decisions (emphasis on “correct”). On the other hand, due to the complexities involved, it is not reasonable to expect a one hundred percent success ratio in all transformation involved decisions. What are the performance expectations? Unlike in baseball, for example, where a 40% batting success ratio would ensure you riches and your name in the Baseball Hall of Fame, in the business world a success ratio of 40% would get you only in the Hall of Shame. If you achieve a Pareto-like 80% success ratio in any of the myriad of low to middle impact decisions you may make, you’ll be doing fine. But when it comes to major decisions, you’ll have to consider yourself lucky if you’re able to survive one major blunder, let alone two.
Admittedly, this analysis may be slightly facetious since the truth of the matter is that often the criteria for success is not a binary right/wrong and tends to come with a high degree of fuzziness (that’s why the art of “spin” has evolved to the point where it is now). The point remains: a necessary (but not sufficient) attribute of good leadership is the making of correct decisions. Many projects get derailed because those in leadership made decisions that were either too conservative or too aggressive (depending upon the circumstances) or too political or too vague or plainly just wrong.
Don’t believe those who say that leaders need not be knowledgeable on the problem domain (“as long as they surround themselves with knowledgeable people, they’ll be fine,” the saying goes. That might be true for managers; not for leaders.). Fact is that making the correct decision is not possible if you lack the knowledge to at least determine what is right from what is wrong. It helps if, as a leader, you have experienced a transformation project while working as a foot-soldier as you will have gained a broader perspective that gives you a better frame of reference to help you make the right calls. Moreover, it also helps to be humble in accepting the fact that, no matter how knowledgeable or experienced you may be, it is impossible to know everything. The best kind of knowledge is the one that gives you a clear view of your limitations. You should be sure to surround yourself with a trusted team of collaborators who can expand upon the knowledge you have. A second key attribute of leadership is to know how to listen to your team and others.
In his book “Infotopia” author, Cass R. Sunstein, writes about the Jury Theorem. This theorem states that the probability of a receiving a correct answer, when applying the rule of majority opinion, increases towards one hundred percent as the voting group increases. The one caveat is that for this to work, each member of the voting group should more likely be right than wrong. A group of experts voting on an answer will tend to be more correct than a single expert making the decision, for example.
The theorem also shows the opposite: if the individual members of the group are more likely to be wrong than right, the resulting probability outcome for correct decisions will trend towards zero. In other words, you should seek answers from your team, provided your team’s experience makes them more likely to be right than wrong. The opposite is also true; don’t ask people to give you advice about things they don’t know enough about.
I once attended a “decision-making” meeting where the boss at that time, trying to appear inclusive, invited opinions and votes on whether to follow a particular technical approach. This was a subtle and complex technical question, mind you. Problem was that in the room they were only two actual technology people; the rest were non-technical: the HR guy, an accountant, the boss’ assistant, and a couple of administrators! Only one of the non-technical individuals had the courage to answer “I don’t know. That’s not, my thing.” The decision was based on straight up and down vote regardless and, needless to say, the decision adopted that day was a wrong one.
Now, I am not saying that decisions cannot be taken by multi-disciplinary teams; just that the team you gather to make the decision should have the appropriate relevant domain-level expertise. Provided you do this, it’s best to approach the art of decision making with the objective to reach consensus based decisions (but consensus does not imply unanimity!). When facing a problem it makes sense to gather your trusted advisors and proceed to methodically evaluate each approach; keeping an open mind when considering any solution proposed as part of the brainstorming exercise. Basic pruning principles are the Occam Razor principle (also known as the KISS principle for “Keep It Simple, Stupid”), indicating that given two alternative choices, you should always lean toward the simpler one as common sense solutions are to be preferred. In the end, leaders should not assume that this process of consensus making is the basis for abdicating responsibility for taking a decision. At times project leaders mistakenly hold back on a decision far longer than advisable because they seek consensus at all costs. Ultimately, there should be the realization that not making a decision is no different than making a decision to do nothing. If you are comfortable with the impact of doing nothing, then fine, but you should realize that, on occasion, consensus will not be possible and you will need to make a call based on your gut feeling. You might even sometimes cash in on your prerogative as “the decider” to overrule a recommended decision from your staff. Beware of exercising this right too often, however, as this position should only occur when you really feel strongly about your decision and have objective elements (i.e. “knowledge”) to defend it. Either way, you should always allocate the needed time and effort to ensure the decision, and the reason behind the decision are timely communicated to the staff and all appropriate stakeholders.
Finally, leadership is not about managing. Managing is not difficult if you follow the method laid down through the generations. Good management is a science, but leadership is an art. The third attribute of good leadership is in treating your team with respect, motivation and inspiration. Management is something you can draw on an organization chart, but leadership is something that gets engraved in the trust of your collaborators. Leadership is about making certain your team knows they are building the proverbial cathedral as opposed to a church wall, and that they are encouraged to take ownership for the success of the project. Leadership helps ensure everyone on the team feels comfortable about the viability of the objectives, and that appropriate recognition will be shared with everyone upon the project’s success.
Because leadership is all about success, it is only natural that while people have to follow managers, but people will want to follow leaders.
 Making decisions based on “gut feelings” is not necessary that bad IF and only IF you have experience on the field related to the decision, and not on blind faith. In fact, author Malcolm Gladwell shows in his best-seller book “Blink” that experts develop this ability to make appropriate decisions in their field of expertise almost sub-consciously.
Friday, May 21, 2010
Well, you’re going to need to augment your work force with external resources. Think of the augmentation strategy in terms of layers. At the core, you have your trusted employees as your resident resource. The core team is the base and lever of the project. In the next layer are the in-house contractors. These are resources brought in by a third party companies who work as part of your organization and will be paid on an hourly basis. The strategy is to implement an option-to-hire policy so that, as you bring in the much needed expertise, you can also exercise the option to hire those contractors who prove worthy of becoming part of the inner core.
In yet another outer layer, you have the augmentation resources provided by external companies working on a statement-of-work basis. While this model allows you not to have to deal with the day-to-day management of these third parties, and you will not have visibility to each individual resource contributing to the effort, you should nevertheless be prepared to exercise appropriate ongoing oversight to ensure deliverables are met and that you are not surprised by missed deliverables.
Some like the idea of using outside contracting services on a per hour basis. I don’t recommend this approach. The only exception would be for trusted former employees who for personal reasons have left the company but still wish to continue working, albeit remotely. Otherwise, external per-hour contractors should only be used temporarily to fill specific gaps in expertise, as subject matter experts. Should you face this need, it is best to secure these outside resources on a retainer mode rather than on a per hour basis (how is it possible to oversee the number of hours clocked by someone working remotely, anyway?). Examples of resources best used in this manner are: DBAs, architects, security advisors, and performance engineers.
Finally, some companies prefer to use off-shore resources either via statement-of-work or on a retainer basis. I personally feel that most companies are ill-prepared to directly deal with off-shore resources (cultural and geographic concerns apply). My recommendation is that, if off-shore resources are to be used, that they be managed by a local third party contractor who will take responsibility for the day to day interactions with the off-shore outfit. Even better, it is also now common for the off-shoring company to keep a touch point local presence. Still, off-shore services should only be relied upon for very specific, non-mission critical components that can be developed with a minimum of explicit functional description, and should never, never be used for core, mission-critical deliverables. Valid assignments for off-shore work are: reports, data mappings (ETL), general tools development (diagnosis, test tools, etc.)
You should also adjust the way you augment resources vis-à-vis skill sets and specializations. A development project that has a well qualified team of developers and a few good project managers will perform better than a team composed of many good project managers but very few qualified developers. The prized quality of good project managers is his/her ability to enable the work of the developers and then getting out of the way as much as possible. I have seen enough horrors stories of management trying to fix a project in trouble by adding more and more project managers! As if a sinking ship needs more captains instead of buoyancy! The best project management work I have seen comes from project managers who were hired as outside resources as they tend to focus more on the delivery of the project without having to worry about internal governance disputes.
Likewise, many prefer to engage the services of external consulting firms to design the high level architecture plan. Needless to say, these high end services are usually very expensive. In any case, it’s best when the architecture is developed by an internal team. Nevertheless, I can see the involvement of external consulting powerhouses in helping to refine specific specialized niches in the architecture. External consulting firms are also often used to “audit” a given architecture or project implementation, but my feeling is that they are usually used in this function when a project is already in trouble or, frankly, when executive management feels the need for external validation of the project. In all fairness, this validation may not be indicative of lack of trust of you or your team, but simply a necessary CYA to better defend the project to the board or to regulatory entities.
In any case, the architecture team should definitely be part of your core team; not augmented with external resources. You still need to have a dedicated architecture team to lead the technology side of the project since the expensive, high level consultants will probably be long gone once the project begins to get intense. The architecture team should be in place to develop the common framework modules; perform R&D on new components, and in general serve as an enabler to the programming community at large. They should establish the desired architecture by example, and they should also be able to establish governance whereby line programming staff has the opportunity to voice their views and preferences in influencing the architecture direction. As discussed earlier, the architecture team will have a number of roles, from defining architecture to enforcing it. Keep in mind the key dictum that the architecture team should also do programming. If you create an architecture team whose only responsibility is to create architecture, they are bound to become like the gods of Mount Olympus handing down un-implementable architecture specifications to the mere mortals in programming.
Finally, nothing will ensure the success of your project more than a strong group of developers, even if this means you will have to sacrifice the size of the team in order to achieve a higher degree of quality. Measuring the performance of a group of experienced programmers has shown that the difference between the best and the worst performance averaged a factor of 10 to 1. Think about it: a good programmer is on average ten times more productive than a lousy one!
Getting great programmers is, of course, never easy. If you identify great development resources to augment your team, try to bring them onboard in any capacity you can. Beware of the prima-donnas (the best programmers are often the ones that brag the least). They can be contractors or consultants or, if possible, you should hire them. You should be prepared to pay better than market salaries and entice them to join your effort in light of its exciting challenges. Good programmers go for the thrill of the challenge even more than they go for the salary.
There are some who say that IT departments in your average Fortune-500 company can’t aspire to the recruitment of top development talent. The allegation is that good developers prefer the smart, entrepreneur, technology-led start-ups over those big boring corporations. I’m not sure that I subscribe to this view. Granted, many of the brightest want to make their fortune quickly and so head for the cool and sexy frontiers of new development. However, cool and sexy can also be an attribute of a transformation technology project, and I do believe that a well-formed and well-led technology transformation project will appeal to many a talented programmer.
Friday, May 14, 2010
Other than with start-ups or other new ventures, when it comes to employee resources, you’re going to have to deal with a varied mixture of “legacy” skills and attitudes. It should go without saying that any serious transformation effort is going to face a certain amount of resistance and push-back—especially from those who rightly or not feel threatened by the change represented by the transformation. Building a team supportive of transformation will require a great amount of patience, good communication and a dosage of well-focused leadership.
A famous sculptor once remarked that creating the statue of a horse from a block of granite was all about removing the “non-horse” parts from the block. No matter the organization, there is always an existing team that can be crafted via training and reassignment to support the transformation goals. As with the proverbial sculptor, you will need to remove the “non-team” parts represented by what might be an ossified and unmotivated staff (pardon me for sounding so Zen-like!).
Traditional team dynamics demonstrate that the greatest resistance to change is usually generated by just a few. Since it is not realistic to assume you will be able to completely create a brand new technology team, your mission then is to weed-out the unredeemable trouble-makers from the working-bees who are perhaps afraid of change, but are nevertheless professionals who will gladly follow through once they’re given a clear direction. As a bonus, with the benefit of fresh eyes and renewed objectives, you will also be able to identify the diamonds-in-the-rough, the unappreciated team members who have been waiting patiently for a chance to shine (and believe me they exist in every mid or large sized organization) but had never been given a proper role to play. When given a chance and a fresh challenge, these individuals can become natural stars when allowed to spread their wings.
Add to this dimension, the need to make a frank assessment of the skills of those in the group vis-à-vis the skill-sets needed for transformation, the time and funding available to repurpose these skills, and the realization that you will need to fill the natural skill gaps presented by the introduction of new technologies. Consider too the fact that, yes, you are dealing with human beings, not machines, and you can see why this area of the transformation process is usually the most sensitive and difficult. It doesn’t matter if you have the most wonderful architecture in place, or that you are using the most amazing technology, or that your project plan is a paragon of beauty, if you can’t deal with the human dimension, the project will not succeed.
Dealing with this type of challenge requires a clear understanding of team inter-relationships. Most importantly, it involves applying a wise combination of informed intuition, fairness and decisiveness in order to resolve or remove the elements that might impede the effort. In the end, once you have defused those interested in obstructing the project, you will be able follow the kind of staffing plan that allows you to make delicious lemonade from the mix.
In the end, when staffing the new system with existing resources the approach to take is one that requires a case-by-case assessment of individual competencies and attitudes. Work closely with your Human Resources team to do this. When defining a more appropriate taxonomy of the various skills in your existing area, you will find that certain workers can be retrained to handle new technologies.
The diagram above shows a generic, sample roadmap of how different resource types can be utilized for the new system. Business analysts, for instance, will usually have the easiest transition simply because the business processes supported in the new system are, for the most part, the same as those of the legacy environment. A few motivated legacy operators may be able to continue operating the new system after significant retraining, but many might be better off assigned to performing Q/A functions on the new system—after all, who better to spot inconsistencies or trouble in a new system than someone already acquainted with the operation of the old?
Alas, you will also find that a percentage of the existing workers will never be able to switch to the new system under any capacity. The latter are more likely to be seen in environments that have sustained investment in legacy technologies over many years. In this type of “stagnant” environment you are more likely to find a core team of, say, COBOL programmers who, when faced with the possibility of losing their employment, will demand to be allowed to code in Java.
Truth be told, someone who has been working for decades with procedural languages such as COBOL will not have an easy time moving to modern object oriented technologies. Object orientation is more than learning the syntax of a new language. It’s also about dealing with the conceptual shift represented by object oriented concepts and development methodologies. Some of the most serious coding disasters I have witnessed involved programmers given responsibility to develop mission-critical applications using new programming languages they were completely unfamiliar with.
I realize that what I am saying may not sound politically-correct, but the reality is that only a handful of procedure-oriented developers will ultimately be able to manage the transition to utilizing new technologies. You would do better to focus on college graduate with baseline training in modern systems, apprenticing them to those on your current staff. Does this mean that the old-timer’s only route is retirement? Not necessarily. A proper analysis of the skill-sets in your organization can be well-timed to use each employee’s skills in a way that is consistent with their abilities. For example, while the traditional COBOL programmer might never become a Java developer, there is probably no one in the organization with better understanding of the business rules and processes than someone who has been implementing these applications for years. Perhaps it is time for the COBOL developer to consider retraining as a business analyst or a quality assurance tester?
The mark of a good leader is not in his or her ability to wipe a slate clean, but rather in his or her ability to identify the various hidden strengths inside the organization and to make everyone contribute to the maximum of their capacity. That can only occur, however, when one is completely honest about how unrealistic it is to try to make change happen without ruffling feathers. That is, after all, the nature of change.
Friday, May 7, 2010
In addition to having a strong, effective architecture group, you must create a group dedicated to SOA. Since the data governance has historically been well defined for the roles of Data Base Administration, Data Analysis, and Data Architecture, there is a tendency to also organize SOA in a similar manner to DBMS governances. Don’t. Services are not data. While it is true there may be some similarity to the work of DBAs and SOA Service Analysts (e.g. Data Base Schemas vs WSDL Interfaces), SOA is so different enough, making it wise to establish the SOA governance separate from the data team.
Make this SOA governance responsible for the following service life-cycle areas: service interface validation, testing, service repository management, service deployment, versioning and services sun-setting. Note that since the actual service development is performed by the actual development organization, the role of the SOA Group is one of coordination and control. This function usually consists of a small group (two to four individuals) whose role is similar to that of a Data Base Administrator, but with a special focus on all things “services”.
In the diagram above, the SOA Group covers the roles of Service Analyst(s), Repository Manager, and Service Librarian(s). Of these three, only the Service Analyst is required to have a programming background (the stronger, the better!); whereas the Repository Manager will have a background related to operations (someone with experience managing LDAP servers comes to mind). The Services Librarian may well come from a data organization.
It is essential that the team be formed of very competent staffers. Now, before you say “Duh, that’s obvious!” let me remind you that we often fail to elect our politicians based purely on their competency. We vote for them because, “He’s the type of guy I could have a beer with,” or simply because we like the image he projects either or his fashion style. As managers, we often incur the same biases and tend to empower those on our staff who better match our ideal image of competency. It often happens that when forming a new team, it is often with “volunteers’ from other groups who want to escape their current roles instead of wanting to contribute to the new group. Don’t make the SOA group the Gulag of IT.
Competency does matter, but it is not always easy to define “competency”. Recently there has been a trend to evaluate employee competencies around the concept of “certifications”. For example project managers are expected to show PMI (Project Management Institute) certifications, testers have their own certifications, DBAs get their certifications (usually from DB vendors), and so on.
Entire industries have been spawned from the certification business. Now, I am not suggesting that a certification is a bad thing in and of itself, but I have met many who have specialized in collecting all kinds of certifications and yet are not particularly competent. I suppose I could give them a certification for their ability to obtain certifications, but that’s about it! My point is this: be suspicious of anyone flashing a long list of certifications. Either this individual has had too much time on his or her hands and has not been focused on performing actual work, or this person’s certification portfolio proves he’s a genius; making you wonder why the need for all those certifications in the first place. Forget the diplomas. Ultimately, competency is something that an employee either has or hasn’t. You’ll know if he has it by what he delivers.