Cable in the Car

Over the holidays, I invested in a Sirrius Sportster for my wife’s car. My wife not being a big sportsfan, I convinced her that the Sportster’s functionality as a mobile sat receiver was useful. Great sound, many channels, low monthly fee, commercial free-take anywhere music. I liked it. She loves it. It made for a great holiday gift.

My brother in law called in “Cable in the car”. Not far off. Except I think the medium might change. Consider one technology, the WiFiMax/ETSI HyperMAN wireless standard. 75mbps throughput on a 30-mile carrier; imagine total wireless anywhere – hotspots = moot, everything = connected, cell phones and land-lines = displaced by mobile VOIP solutions; more drastic competition into LD, LEC, and cellular/PCS services means connectivity on the cheap for consumers; imagine radio, TV, movies – anything can be piped anywhere.

Think of it: universal and near costless connectivity available everywhere in a metropolitan area near you!

Cable in the car, absolutely; cable in the air, most likely. In light of WiFiMax, Sirius and XM may be a leap-frog stage in subscriber radio. Woops, maybe we should have let Howard Stern in on the secret? It was because of WiFiMax alone that I didn’t invest in the $500-for-life subscription. Who knows – Sirius may just become the betamax of our digital radio future…

Russell Mickler, CISSP/MCSE

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003,2004. All Rights Reserved.

None of this material can be copied or used without express permission from the author.

E-Christmas

I was never alive for Christmas. Well, Christmas the way it should have been. Maybe Christmas the way it was. Perhaps the way we all wish it were. Here’s what I’m trying to say:

• Christmas should resemble more Norman Rockwell and less “Christmas with the Cranks”.
• Christmas should be more about caroling in a front yard than obnoxious inflatible blow-up dolls.
• Christmas should be warm, spirited, full of family, fun, and winter frollick.
• Christmas should not be about whether I got everything I wanted and, if not, how affordable plasma and HDTV’s are so I might get one for myself.

Radio. TV. Spam. Pop-ups. Marketing, glitz, message, reminders – the intrusion of Christmas comes only once a year; haven’t we neglected spending on our selves the entire year? Why shouldn’t we indulge since those ungratful spouses and family won’t get us what we really want, what we really need.

Meier and Frank with their talking feminine packages wish to remind me that “it’s all inside”. Coke’s polar bears. Corona’s Christmas palm tree. The endless drone of Walmart’s Gingie-rip-off cookie between “Rudolph the Red Nose Reindeer.” Christmas movies at a 16-screen cinamaplex, shopping malls, in store credit, 12oz egg nog lates as Starbucks for $2.95, inappropriate “wanding” in airport security, self-checkout at the department store, the kid handing me printed product comparisons for game consoles, online shopping and estimating how long it will take UPS to air-drop a package to Idaho, and cut-out cardboard people to ring an electronic bell and take your money (http://www.macon.com/mld/telegraph/10342006.htm).

That’s not Christmas. None of it. It’s not Norman. This is Christmas-electronic. This is Christmas-excelerated. This is Christmas by email. This is E-Christmas: capitalism on steroids.

I long for the beta of Christmas. Christmas before the enhancements. I’d like to uninstall the E-Christmas upgrade and go back to what really mattered during the season; to daydream in a moment captured in an imagined time, in an imagined place, in a Christmas that should be but may never have been.

Russell Mickler, CISSP MCSE

(C) 2004. Mickler & Associates. All Rights Reserved.

www.micklerandassociates.com

Repost: The Power of Perceptions (9)

The Power of Perception (9) – Leadership

Originally Posted: Wednesday January 21, 2004

It is said often enough that I might sound trite to reiterate that no one inherits the ability to lead, and poor leaders are often the beneficiaries of what might be perceived as leadership in the vestiges of rank and position. The often-spoken truth is that one must develop the ability to lead. It takes time, personal observation, and a keen eye for the perception of your actions in another’s eye.

Take inventory:

§ How is Your Personal Integrity? Anyone in a leadership role understands that the stakes are too high to gamble leadership on a dishonest person. The statements of a leader are made as plain and unadorned fact. Words and actions are interchangeable for a leader – they say what they mean and mean what they say. And when a leader gives their word, they keep it.

§ How is Your Knowledge and Skill? The art of knowing is of particular importance to the information systems officer. Nobody in technology takes you seriously unless you strive to become an expert in your specialty; even as a generalist, the information technology manager should stay current on trends, tools, and the industry buzz. You should know your job and be able to pass what you know on to those who work with you. Remember: it is okay to admit that you don’t know the answer to a question – admit it, but then find out what the answer was and follow-up with your stakeholder. Put confidence in those who deserve it; give closer supervision to those who need it.

§ How Often Do You Display Courage? Courage grows with action. Support from others comes when they understand your vision, when they trust who you are and what you say you will do, and that you’re knowledgeable in what you do. When things are tough and times are tight, take action – be visible and make a positive statement. Rally those around you to buy into your vision, and execute a plan. Positive action based on a poor decision is better than a half-hearted response to the best possible decision.

§ How Often Do You Act Decisively? Get the facts, all of them – not some of them, not a couple of them you heard at the water cooler – all of them and execute. Facts are critical in making sound decisions; jump too quickly and you will be perceived as reactionary; jump too late and you will be perceived as inept or missing the boat. Make up your mind when you’ve weighed them then issue your decision in clear, confident terms, and put your plan into action. Don’t wait for tomorrow. Do it now.

§ How Often Do You Take Initiative? Think ahead and stay mentally alert. What opportunities exist that others haven’t seen – what can lend you or your organization or your client a competitive advantage? Do what others are afraid to do. If you see a job that needs to be done, don’t wait to be told – go do it. Be for others a true model of “empowerment” – ugh, such a trite term, but truly – do not wait for the queue of bosses, committees, or peers. Take the initiative and lead.

§ How Often Do You Make Just Decisions? Don’t play favorites. Keep anger and emotion out of your decisions. Get rid of any narrow views that you might hold about a particular race, creed, or section of the world. See the environment through objective and patient eyes. Be fair, explain your decisions in ways that are clear and transparent, and be genuinely consistent in your treatment of others.

§ Are You Tactful? The tactful leader is fair, firm, and friendly. A poor leader is one that demands obligation or compliance from fear, extortion, or exploitation. Handle yourself in an unwavering sense of grace and pride, and treat others in means that you would wish to be treated yourself if the tables were turned. If an individual needs disciplining, then go do it – in private. It is helping no one by saying nothing and damaging everyone by saying something in the public eye. On the other hand, when someone has done a great job, let everyone know about it.

§ Finally, How Do You Show Your Enthusiasm? It’s a fact that the more you know about something the greater your interest and enthusiasm will be. Enthusiasm is highly contagious. Set a goal, promote it, and put everything you’ve got into the task. Your momentum will generate zest in yourself and in others. And they will follow.

I think I’ve concluded Perceptions. In the next series, I’ll concentrate on preparing for career success in the field of Information Technology.

Russell Mickler, CISSP MCSE(micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003,2004. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (8)

The Power of Perception (8) – Physical Appearances

Originally Posted: Monday January 12, 2004

I realize that this subject may strike a chord with many. Thus, please forgive should I offend but exonerate if you realize I’m right.

Although I have it on good authority that girl geeks run contrary to conventional opinion (http://www.igeek.com/articles/Career/FemaleGeeks.txt), I don’t believe it would be an understatement to suggest that male geeks lack a certain sense of style. For a moment, consider the geek ego. Fashion consciousness is superfluous.

Generally, technical professionals are engineers used to crawling under desks or working in a dank telephone closet for most of their day; they’re reclusive sorts who spend as many of their waking hours as possible in front of a monitor; maybe they’re a slave to the ACD and interact with customers only through the pleasantries of their voice; they’re highly eloquent when around others of their trade yet shy away from unpredictable social engagements. After all, a good knowledge of fashion doesn’t build you a better computer, troubleshoot a network, or provide higher quality code. Basically, the geek dresses to publicly state their non-conformity and superiority: I am smarter and faster than you, and I don’t have to wear the Gucci’s to prove it.

Unfortunately, nothing screams disaster for a project quite like a tech with a half-shaved head, baggy jeans, a colorful nostril ring, and a black t-shirt reading “Bite Me”. Hits hard to home, huh? Yes, the technical manager may even recall being that way themselves – being young and uber-confident thinking that the company needs them more than vice versa. Those were the days. But we grew up. We realized that the opinions of our customers or boss had a direct relationship to our compensation. So we changed. Yet, the manager may feel some empathy for the statement the young geek is trying to make in a meeting in their choice of clothing, garnering a Dirty Harry approach to winning the trust of others by bluntly suggesting, “Go ahead. Say something. How lucky do you feel today, punk?”

Communication can be over any medium these days. Yet we meet in person for a reason. Public meetings have an importance that should not be underestimated and they exist as important opportunities to win the support, favor, and trust of our stakeholders. Socially, the importance of the public meeting is to build trust and establish working relationships. As a technology manager, we must inspire confidence to be effective. Hey, it’s as much packaging as it is window-dressing, but the suit wins the mind of your audience way before they have a chance to meet yours. As consultants, we’re convincing others to expend scarce resources. As employees, we’re part of a professional team. Being a technical manager means we have to dawn new clothes.

Dressing the part of a bureaucrat seems like the ultimate compromise in our principles of geekhood. The tie, the slacks, the jacket, even the shoes are meant to distract from our one core asset – our intellectual prowess. Should we reject the notion that a suit delivers a better technology project then we overlook the necessity of trust and the human relationship. If we are to thumb our nose to convention and dress in a manner that is all together unconvincing or undeserving of that trust, then we’re not apt to go far in our professional career. The perception would be that we value our non-conformity over the seriousness of the project. And nobody is going to be eager sign a check for you if you visually grain against their principles.

Action Items:

1. Where do you want to go in your career? Is management in your future? If no, then don’t buy the tie, slacks, or jacket. If so, start budgeting. It’s like they say: dress for the position you want to have. Start tomorrow.

2. Ditch the t-shirts. In the least, get some tan dockers, brown shoes, and some button-down shirts. At the most, get to know your neck size and arm lengths and get some nice white dress shirts and some slacks.

3. Have a troublesome staff member? Discuss their future with them. Identify where they want to go and what kind of impression they want to make on others. I had a similar conversation with two of my employees. Two weeks later both appeared in nice suits to prepare a presentation to our internal customers, a move that undoubtedly instilled more confidence in our team’s ability to execute. They were more confident and more successful than ever before, and all because they considered the perception of their dress.

Next time – leadership.

Russell Mickler, CISSP MCSE(micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003,2004. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (7)

The Power of Perception (6) – Constraining Emotions

Originally Posted: Friday January 9, 2004

Interestingly enough, the Portland area has suffered a most severe snowstorm. It’s prevented me from updating this blog and from attending regular work. Apologies – time to move on!

It is needless to say that technical projects create tension. Technology is ever-evolving. IT often requires new components, new training, new understanding from your staff and stakeholders. What is created is soon replaced. Tension results as much from the unknown as from the control over finite resources: time, money, and labor. And aside from all this, there are commitments to keep and egos to satisfy and principles to uphold.

Tension is an everyday part of work yet is a great burden for the IT manager. I am reminded of the CDW commercials where the ever-calm IT Manager walks around an office of personalities reminding him of projects coming due, servers that cost too much, and file shares that were erroneously deleted and need to be recovered. And through it all, we aren’t phased – it’s just another day at the office.

Great IT managers learn how to constrain their emotion and harness tension into productivity drivers. Instead of being swamped by the negative, the IT manager should attempt to turn what remains into a positive. IT managers need to filter out the signal from the noise – drive through what’s really important and encourage others not to sweat the small stuff, all the while remaining positive and pessimistic. Like the staunch mission controllers from the Apollo 13 movie, technology managers require a significant clarity of thought to perform their work – they are at the command of many scarce resources, and at every pitfall they must project an inordinate amount of optimism for the larger vision.

Inasmuch, the IT manager must separate their personal feelings from their work. Opinions about people, events, timeframes, constraints, ramifications can be constructively channeled into business-level action plans. But once all formal channels have been exhausted, the IT manager must put on a positive face and continue the project – carrying out the will of the customer, stakeholders, or executive team. This is difficult to do. It is not easy for many to ignore their empathy for front-line employees that may be replaced with their technical solutions; it is difficult to build relationships which could eventually lead to layoffs or terminations. Further it is difficult to separate our emotional attachments to projects that we’ve invested a lot of time and energy into. And it is especially challenging not to share our opinions with others on our staff.

Regardless, good managers learn to become good poker players. The success of your career and your projects depend on your ability to manage finite resources to the expectations of many stakeholders even if their outcomes compromise our emotional investments. Extreme displays of emotion – even minor ones – can give others the impression of volatility. Your effectiveness depends on your willingness to cooperate with the will of others. In essence, it proves whether or not you’re a team player.

You’ve met the type – many technical professionals can have a strong sense of idealism that lead them to pronouncing their favor or distain for something in a very public way. Maybe it’s through email; maybe in meetings; maybe in a memo; maybe in the corporate kitchen or at lunches; you can always depend on this guy voicing some negative naybobism about something. Negativity is infectious. Others of lesser wills may be so dominated by “Negative Nay-Bob” that their own perceptions of projects, people, and initiatives are tainted. Even more so if such negativism is pronounced by their manager on some high-minded bully pulpit. In his mind, the Negative Nay-Bob is a hero – a champion of the people – standing by principle and resisting the inevitable.

Don’t be a Negative Nay-Bob. Channeling these energies into something constructive – whether they’re from you or from others – is of paramount importance; it’s the challenge of any manager. But allowing such passion to become a stubborn obstacle to your effectiveness will ostracize you from decision-makers. Worse, it pollutes your constituents with adversarial perceptions towards and project and diminishes your success factors.

Action Items:

1. Wait before responding to email. The immediacy of the medium prohibits clear rationalization how what you say might be perceived. Try to restrain the immediate compulsion to respond with what’s on your mind, right then and there. Breathe, take a moment to formulate your communication, and respond when tension or passions aren’t quite as high.

2. Generally, do not articulate strong negative opinions of projects in front of your subordinates. Be positive in all things. Do not curse them with the stigma of your own negativity. Be a leader. Accentuate the positive or business need of a project and convince others in your vision.

3. Squelch the Negative Nay-Bob. Meet with such people directly and try to get them to channel their concerns into productive activities. Complainers often stop complaining after being offered a chance to remedy their grievances. Either they’ll embrace the opportunity to lead change, or, they’ll shut up next time in fear of being called to the carpet.

Next time… physical appearances.

Russell Mickler, CISSP MCSE(micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003,2004. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (6)

The Power of Perception (6) – Perceptions and Technical Planning

Originally Posted: Monday January 5, 2004

Happy new year to everyone!

Continuing this thread, I’d like to skip what I promised in the last entry. For now, I would like to briefly touch on the importance of perception to preparing and executing a technical plan. As technology manager, a component of your job is to provide leadership, vision, explanation, and to convince others of your vision. Where the executive team creates a business plan that describes markets, capital, spending, and competition, you are applying technology in ways that address the business plan – reducing fixed costs, expenses, and creating competitive advantage.

Creating a documented plan improves visibility over projects. It affords public review and critique. A plan grants an opportunity for feedback and to articulate priority. Not to be confused with consensus, sharing a technical plan for any project shifts the personalization of risk from the technical manager to the larger community or organization; especially if everyone bought into the plan to begin with. Besides, it goes without saying that – internally – if the troops can see where they’re going and are motivated to get there, then you are more likely to have captured their enthusiasm. And over time, with each proverbial hill captured, the big picture is easily brought to light to reveal the genius of your plan and the success it has achieved.

Too often, technology managers will fashion a plan without correlation to the business plan. This is a common shortcoming. Without direct integration between a technology and business strategy, the technology manager risks concentrating scarce resources in superfluous activities that place the organization at a competitive disadvantage, or, make the organization incapable of capitalizing on an immediate opportunity. Approaching this problem, the technical manager is wise to expose their planning to the executive team for review and comment, and be open to postponing rather _delicious_ technical projects for more specific business requirements. Not only will you likely receive constructive criticism on priorities, but the technology plan will be tightly integrated with the business plan.

Further, it is common to find technology managers preparing technical plans without input from their stakeholders, subordinate management, or line.

On a personal level, I had a problem embracing this reality. Many times had I attempted to put together a technology project without sharing the plan with others and many times had I created enemies in the process or had failed at my plan. I had assumed that I understood all the risks and variables of the effort and that there was little need for commentary. This assumption bordered on arrogance. My disregard to perception isolated others and I could not get buy-in. Further, I could not articulate resource requirements from other functional managers. How could l hope to execute my technical plan if I couldn’t communicate what was needed?

Perception is an unforgiving task-master: we must actively seek the involvement of others in preparing our technical plan, even those whose opinions we’d rather avoid. Laying the foundation of a technical plan and allowing others to scrutinize it – to be totally transparent – is the foundation of good management. Your success won’t come because your decisions were made in a vacuum. Success will come when your constituents have faith in what you can do and can see your work execute in accordance with public expectations.

Action Items:

1. Document and publish a plan. Like a captain at the helm, much planning and preparation must go into making any voyage; each voyage should lead to some larger, more meaningful campaign; and everything should have some larger purpose that benefits the Crown (or, in this case, your company).

2. Circulate the plan to others. Gain feedback and appreciation for diversity in opinion. Make changes to your plan to meet the perceptions and expectations of others.

3. Integrate your plan with the business plan. Attempt to bring relevance to every technical project or initiative to the broader goals of your executive team. Demonstrate risk where lack of capital funding in technical projects are directly related to a business objective.

Next time … constraining emotions.

Russell Mickler, CISSP MCSE(micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (5)

The Power of Perception (5) – Perceptions and Contractors

Originally Posted: Wednesday December 31, 2003

Indeed, most managers will handle a relationship with a contractor differently than a relationship with an employee. Unlike a normal employee, the contractor is expected to perform at a high level of competency – why else would they be paid the big bucks? In a typical scenario, there is a specific problem that requires immediate attention and the expectation is that it will be completed in the more efficient and effective way possible. On the other hand, the employee expectation is more lenient; their skills nurtured over time at a lower cost and it’s understood where their responsibilities and skills peak. Therefore the perception with the employee is a reasonable fixed cost where efficiency and savings are earned over time, whereas the contract is a variable cost whose time and material must be tightly constrained.

Continually managing perceptions with the contractor, their role, and their performance benefits the project and your relationship with the contractor to make their work as smooth, efficient, and effortless as possible.

As IT manager, it is often your role to articulate a scope of work (SOW) for the contractor and sometimes that’s where your responsibility might end. After settling fees and terms of service, the contractor steps into the work environment without an understanding of the negative spin surrounding the project, the personalities governing the project, or the stakeholder’s perceptions of immediate priorities. Inasmuch, the contractor is at a disadvantage. Although they understand the procedural requirements of the SOW, they don’t understand the user community’s priorities, or, differing managerial perceptions of pet projects, severity, and importance.

This leaves the contractor to make these decisions on their own, graining against the perceptions of others which may anger constituents both above and below the IT manager. In good faith, the contractor may head down the wrong path and earn a negative perception of his work, his company, and your ability to manage them.

Action Items:

1. Give your contractors a competitive advantage. Once they review the SOW with you, articulate the internal perceptions and help establish priorities based on perception. A good example of managing this kind of situation is with a telecom environment where the choice of fixing a PBX over re-establishing WAN connectivity may be on the docket. Fixing the dial-tone first will solve a more immediate problem of communication and instill a sense of trust in your work to recover from the failure; it will set the community at ease. On the other hand, the WAN connectivity is an issue which is less visible and less impacting on the average user, thereby extending their perception of (forgive me) your “inability” to recover from the disaster. Tensions will rise and more demands on your time will be made. Help concentrate the contractor’s work by informing them of local perceptions.

2. Understand that the SOW doesn’t convey the human experience. Don’t be passive and leave the contractor to their own devices. Treat the contractor as you might an employee – try to coach contractors into understanding the unique culture of your workplace and assist them in addressing the needs of your community. Especially over long-term engagements, constant coaching on perception will help orient the contractor to what’s really important. Over time, more trust is built between user, staff, you, and the contractor, and the relationship flourishes. It’s a win-win for everyone.

Next time: Perceptions Continue… restraining emotions.

Russell Mickler, CISSP MCSE (micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perceptions (4)

The Power of Perception (4) – The Consequences of Ignoring Perception

Originally Posted: Monday December 29, 2003

There are varying degrees of risk associated with ignoring perception and some of them have already been addressed in this thread. Primarily, setting perceptions aside in some idyllic effort to consider your actions above public scrutiny is bound to get you in trouble – the stakeholders for whom you’re servicing, no matter what their role, would like a voice. Silencing that voice or take no notice of it is to invite disastrous problems relating to budget and company politics.

Working around perception immediately stigmatizes the IT manager as a loose cannon: a maverick, a nonconformist, a rebel – certainly the cause might be just and your reasoning sound but without perception on your side to justify support, the IT manager can quickly undo the goodwill offered by their professional station or human relationships. This has specific consequences:

§ Lack of trust. Fundamentally, the IT manager has so squandered the perceptions of others that peers and associates distrust his decisions. Soon, the IT manager may find his involvement in critical decisions or exposure to key clients marginalized as to “constrain” the risk associated with a nonconformist. Of all losses due to ignoring perception this is perhaps the most destructive because it impacts the personal character of the IT manager and may seriously detriment advancement or promotion opportunities, the moral support of peers and subordinates, or jeopardize the executive’s faith in the IT manager to carry out a task.

§ Budgetary restriction. There is no better method of restraining the rebel than to choke off his funding. Projects will suddenly lose priority; people will be re-allocated; awards, compensation, and training dollars will dry-up; personal incentives for the IT manager will be removed; financial decisions will likely require additional oversight or micromanagement. The IT manager will be incapable of carrying out but a strict interpretation of their position. This hurts both the organization and the IT manager as management now has to spend more time constraining the activities of their IT leadership instead of working on critical projects, and, it hurts the IT manager in obvious career-limiting ways.

§ Isolation. Without public support and justification, the maverick becomes isolated in their public world; very few peers will stand up to a dissenting opinion in the presence of their own boss, especially if there isn’t wide-spread support for the IT manager’s views from others – a stigma that will fester the IT manager to a point of withdrawing from public forums, empire-building from what resources are left to them, or eventual resignation and/or termination.

Embracing perception is to be aware of the opinions of others and to accept them – right, wrong, extreme, passive, or indifferent. Embracing perception is to give others the impression that you’re willing to address diverse opinion and act upon it. On the other hand, discounting perception is to jeopardize the privileges, trust, and resources afforded to the IT manager’s role. It sets the IT manager on the defensive and more time is wasted waging war than working for the good of the client. At worst, ignoring perception can stigmatize a management team and fragment their leadership.

Action Items:

1. Think surveys. Although trite and arguably statistically insignificant, just the act of addressing public opinion gives more impression of transparency and an intent to elicit feedback from stakeholders. And with web-based services like Zoomerang and SurveyMokey, issuing and managing surveys is easier than ever for the IT manager.

2. Don’t be a victim of politics. Engage the perceptions of management and staff aggressively; avoid defensive postures; never give the impression of an unwillingness to address the needs of others.

3. Articulate risks, not your opinion. In many situations, the perceptions of others may introduce various risks that jeopardize project timelines, costs, feature sets and specifications, or add additional complexity to the coding and testing efforts. The risks of those decisions should be readily apparent. Instead of defending your opinion against the perception, embrace the perception but outline the risks associated with adoption. Allow your peers, your executive team, or the stakeholder themselves to understand the consequences of such action and allow them to assume or deny the risk – leaving you appearing impartial, balanced, a fair administrator.

4. Avoid political spin. Do not badmouth people or projects in front of your staff, your peers, stakeholders, or executive team. Taking sides on issues leads only to political infighting – think twice before sharing your personal opinions. Stick to the facts: articulate risks and benefits, and where opinion must be shared or if it asked of you, be balanced in your approach in sharing it; remember, there are as many good points to an argument as there are bad – temper your opinion and avoid emotional commitment to “liking” a certain path. Where possible, always be a part of the solution and never a portion of the problem.

Next time: Perceptions Continue… Perceptions in Contractual Relationships

Russell Mickler, CISSP MCSE (micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (3)

The Power of Perception (3) – The Importance of Buy-In

Tuesday December 23, 2003

I often underestimate the power of buy-in.

Not sure about you, kind reader, but when considering a project, I’ve already worked out its technical and design merits, resource requirements, and impact on the larger information system in my head. Processing these details allows me to think about timeframes, budget, and priority – you know, those managerial things we’re taught to do in school. Initially, when promoting the project, I develop some high-minded ideal about the project that contributes to the business’ mission based on the technical solution. And oddly enough, I almost believe the solution speaks for itself so what more is there to say?

This is a persistent problem for me, especially when dealing with stakeholders outside the technical arena, whom I forget do not have clue about what the technical design really means to them, their employees, or their work. I jump the gun and rationalize the importance of the solution to the IT department and not to the customer. It’s taken years of self-control to resist the temptation of blurting out “Duh – we should be doing this already, right?”

What happened next was fairly predictable. I would release a project and bring the solution to production without customer buy-in. They didn’t understand why the design was so great, why the solution was so important, and most of all, they didn’t – and I didn’t – understand the WIIFM Principle. Thus, you can imagine the implementation was more push than pull. Nobody wanted to embrace a change they couldn’t relate to or didn’t need.

The WIIFM Principle – What’s In It For Me. I’ve learned to pay attention to this obscure aspect of Murphy’s Law because it is such an accurate indicator of project success. WIIFM is everywhere. Without it, your customers cannot relate to the necessity of using the technology. What is the motivation, for example, to step away from their current business process or tools if the benefits aren’t immediately apparent? If the WIIFM Principle hasn’t been clearly addressed in a project, then early adoption and promotion of the solution will be very difficult – despite the high-minded notions we geeks have over turning the technology on – because nobody “gets it”.

As a technology manager, we have as much a responsibility to explain and promote a solution to stakeholders as we do designing and implementing. It’s our job to draw the proverbial line between the development of a solution and the benefits to the individual. And note the word _individual_. Sure, everyone wants to see operating expenses diminish and profitability improve but else nothing motivates like personal impact; save 10% in inventory holding cost and management will appreciate you, yet save an employee from having to manually handle 700 lines of put-aways every night and you’ve made a friend.

Involving stakeholders, minding user perceptions – right or wrong – acquiring feedback, and tapping into perception to feed into your design strategy in extremely valuable to the WIIFM Principle and user buy-in. I learned the hard way: nobody cares about the merits of a new server but everybody cares about not losing their work due to legacy equipment failures. Building that connection to secure buy-in is just as critical as preparing a great functional spec.

Action Items:

1. Think about the message. There may be more than one, depending on your audience. The project may have a specific meaning to management but another meaning entirely to the line staff, and perhaps another totally different message to your customers. Tailor the message appropriately to articulate the benefits to each type of audience.

2. Relate benefits more often than savings. Think of savings, increased efficiency, and positive budget impacts as byproducts of the operational benefits. WIIFM demands that we spin the project so it has some direct personal meaning to our customers. Remember that 90% of your customers on the line will not know the meaning or relevance of “ROI” or “NPV”.

3. Augment the technical specification and use case with specific benefits to differing segments of your user community. Communicate to the technical team the importance of the perception and the community’s buy-in in making the project successful by acquainting your team with the concerns, hopes, and wishes of the user. Make buy-in and promotion a part of the technical plan.

4. Take feedback, collect constructive criticism, visibly address concerns in open forums, and try to put these perceptions into the design process. As we’ve discussed throughout this thread, perception is everything – try to tap into it to build more stakeholder buy-in.

Next time: Perceptions Continue… Consequences of Ignoring Perception

Russell Mickler, CISSP MCSE (micklerr@hotmail.com)

Principal, Mickler & Associates

www.micklerandassociates.com

© 2003. All Rights Reserved. None of this material can be copied or used without express permission from the author.

Repost: The Power of Perception (2)

The Power of Perception (2) – Traditional SDLC’s Avoidance of Perception

Originally Posted: Monday December 22, 2003

Traditional software development lifecycle (SDLC) processes have four general phases: investigation, design, implementation, and maintenance. Technology managers coordinate events within these cycles, preparing deliverables in accordance to a project plan.

The plan outlines specific roles and responsibilities, milestones, expectations, and timelines that will be involved in deploying the technology to the end-user community. Most of all, a plan clearly delineates a scope of work where the responsibility of one party ends and another begins.

Traditional SDLC obsesses over documentation and functional specifications.

Business analysts and technical analysts review the problem and interview stakeholders. Their results feed into a functional requirements document and a general understanding how the solution will work.

Design involves programmers, DBA’s, artists, system engineers, or other specialists, who perform the tasks necessary to meet the expectations of the functional specification and project plan.

Implementation involves actually engaging the end-user for deploying the solution. Analysts and specialists work to bring the solution to working functionality, meeting or exceeding the functional specification.

Maintenance refers to a part of a solution’s life where active development has been minimized and more effort is expended supporting it in the field. In this case, the solution has met the existing functional specification and requires minor attention.

Thereafter, new enhancements or features may be built into the solution requiring a repeat of the SDLC, beginning once again with the analytical process.

It is through the embodiment of the specifications written by the analysts in the investigation phase that is to become the will of the user community – your customer. Projects and rigorous demands on our analysts’ time focuses their attention on the system design rather than the user need. Analysts will make assumptions. Analysts will walk into a project with pre-defined expectations – entrenched perceptions about their customers, industry, products, and solutions that will directly and deliberately affect the final outcome. Then the documentation becomes law: database schemas are defined in _this_ way; connectivity will be satisfied in _that_ way; system integration will be accomplished like _this_. Think about it: even you, perhaps, have a solid understanding of what AP means, how it works, the type of reports, databases, and interfaces that would be required.

It is as they say: beauty is in the eye of the beholder. Difficult as it is, as the functional specification shapes everything, the challenge for the technical manager begins with encouraging his team to disengage their natural filters and presumptions about the business process, and to open their mind to new ideas and possibilities concerning needs and solution design.

Traditional SDLC bypasses a quality loop process in its design phase. If anything, the quality loop is placed at the end of the implementation cycle with surveys and opinion polls – far too late to have any meaningful impact on design. Just as if a widget had rolled off the production line, because quality wasn’t built into the source of the solution, the user receives a solution they kind of wanted but may not immediately address all of their needs. Much time and money is wasted.

However, new approaches to software design attempt to integrate the customer into every step of the investigation and design phase – more time is spent on the front-end refining specifications rather than on the back-end in maintenance, cleaning-up the final product to meet expectations. Costs are contained, there are fewer surprises, and the deliverables are more to the expectations of the customer.

Action Items:

1. Think about how feedback can be collected and re-inserted into the design process. Routine meetings with stakeholders, customer opinions, one-on-one presentations of prototypes, selective beta and pilot testing are all good ideas. Rethink how quality needs to be built into your process and not come at the end of your process.

2. How can you open up the perceptions of your team to consider new ideas or differing opinions? Instead of being locked into one perception of the client, product, and service, encourage differing perspectives and design – encourage responsible innovation.

3. Consider the perception of the end user. Engagement in the design is the same as enlisting their help; with their help comes a sense of ownership and responsibility in the outcome. A mutual goal lightens tensions and maintains focus on the end result, regardless of what hiccups are encountered along the way. Although the traditional SDLC model attempts to separate user responsibilities from the developer, here, they become a team.

4. Investigate non-traditional methods of SDLC like XP (Extreme Programming) – http://www.extremeprogramming.org/. See how you can incorporate pieces of “fad” approaches to project management into your design process.

Next time: Perceptions Continue… The Importance of Buy-In

Russell Mickler, CISSP MCSE(micklerr@hotmail.com)

Principal, Mickler & Associates

© 2003. All Rights Reserved. None of this material can be copied or used without express permission from the author.