#12: From all you have learned this semester, what are the top five critical success factors for technology change success and why did you select each?

This semester I learned that above all, getting a shared sense of purpose and vision is an essential component for any kind of organizational change.Taking the issue of shared values, along with a strong people focus, systems thinking, realistic planning, and end-user involvement, I think I have left with a strong platform for future success.
I'm in the midst of a significant project at my new job. I've inherited the rudiments of a community of developers: a functional website with the necessary tools to manage content, communications and ongoing knowledge retengion; a delineated process for turning their applications into sellable solutions; a few thousand programmers who have registered as part of the program. And yet, I'm finding that I'm constantly answering the "what's that?" question of my coworkers, the "our phones do that?" question, the "oh, but group x/y/z is already doing that" comment.
Why is this? Because as much as the Senior VP of our group honeslty believes our mission is essential, we haven't seen the benefits of this translated into increased exposure. Our whole group is in charge with data services--encouraging their adoption, providing solutions, resolving technical concerns--yet something like a developer program, which just about every platform- and os-vendor under the sun realizes is a key to success, is a relatively unknown afterthought.
Why did companies like Apple, Oracle, Microsoft and Sun thrive? Certainly, their products were strong. But it was the solid community of developers that they built that allowed their platforms to gain traction and gain from the network effect of increased adoption.
This lesson has not trickled through in my current position. There isn't a shared sense in the company that data is our future, let alone that supporting and fostering a dynamic developer community is our bridge to that future.
How am I going to approach this? Therein come the next four success factors. Making it all about people, first and foremost, is my concern. If we can set the pieces in place to encourage the kind of spontaneous, worthwhile interaction between developers and our company, we will have won half the battle. A dynamic and lively community is a fundamental piece of our growth puzzle. We address developers' concerns, help them out with their needs, and they in turn will deliver the kinds of applications that make our service valuable.
This feeds into the whole idea of systems thinking. While we can have all the knowledgebase tools in the world, the snazziest website around, it is only the self-feeding cycle of good developers building good applications that will allow our program to really become an essential component of wireless development. These developers interact with our own internal processes that provide nformation and support and all the necessary pieces, but which must also contend with the internal perception that we're merely a costly enterprise rather than something with significant reason for existence. Other balancing forces will work within the organization that will slow down our efforts at supporting developers--whether it's customer service that has flaws, networks that have dead spots, systems that won't bill properly, or our own website which is up and down. The interaction between subcultures and smokestacks here is a real variable.
How do I approach this, then? By coming up with a good plan, a solid well reasoned plan that accounts for all of these human and systems implications, that is realistic in terms of budget and time (mine, mostly), and that also can be used as a springboard for a shared vision about how developers are our lifeblood. Incorporate that with an ongoing process of involving our most active developers in refining the website, and I think that I now have a solid plan for tackling this wonderful little beast.

#11: Why are diagrams effective for documenting technology and process designs? What do they convey well and what can't they convey that must be documented in some other manner?

Along with trash television and finding the foreign-food-flavor-of-the-month, writing is a passion for me. As a child in second grade, a small paragraph to be written about a photo of a boy and a baseball glove became a three-page story on magic and growth--my first published piece. My outlet from the pangs of teenage angst were the 10-pages of font-aware correspondence I would inflict upon my then-distant friends. My stories of jet lag and horrid eating experiences have received worldwide fanmail. This makes saying what I will into a writer's apostasy: diagrams are actually sometimes kind of sort of... useful.

No, I haven't foresworn the power of apositives, coordinating conjunctions, and pithy enumerations. But powerful writing requires both time to create it and time to read it. And when it comes to explaining things to people of various backgrounds, writing makes a number of assumptions about people's reading abilities that may be unwarranted. Furthermore, in a business culture addicted to Powerpointing everything, powerful writing ends up being hacked into oversized snippets of text when equivalent diagrams are lacking. Over the wholesale butchery of prose, I will choose dependence on the risky assumption of a collective semiotic vocabulary. Diagrams, as it turns out, can work to explain with visual clarity what it would take much time and skill (and many pages) to describe.

This is particularly important when trying to describe social or physical situations that involve feedback cycles, multivariate cause/effect relationships or layers and tiers of interactions. Senge uses systems diagrams to describe systems, software architects use UML to describe complex applications, and CEOs beyond enumeration use orgcharts to describe who works for whom and where every person in a company fits in relation to everyone else. The complex interactions between groups, processes, modules, functions, tabled and the like can be enumerated and described with elegant sequences of sentences, but the parsimony of double-headed arrows, boxes with text labels, color-coded dotted lines and other artifacts of electrically unstimulated phosphor or liquid crystal is difficult to defeat.

The hit-you-in-the-right-brain power of diagrammatica should not be confused with simplicity of creation. Think of every odious flowcharts with arrows carelessly shot with wanton abandon at unsuspecting process placeholders, every missing (if not inscrutable) legend, every animated-flying-floppy-disk-bitmap you have had the misfortune of experiencing. It may be easy to make a diagram, but it is not necessarily easy to make a good diagram. Indeed, there is an almost mystical power bestowed upon those with the skill of creating effective diagrams: authors like Tufte have grown whole cults around the graphical representation of truth. Still, there are those who would aspire to reach Visio nirvana by wizarding their Crow's foot ERDs and copypasting them onto a slide, without sensing how a simple rearrangement of boxes and lines could not only show the tables and their relationships but also showcase the natural normality of the whole data definition.

So where do I, a word fiend, make my peace with the lines and dots of the diagrammeur? I find comfort in that even the best diagram is often incomplete without a good description. I live comfortable with the fact that while a great image may be worth a thousand words, a bad image is rarely sufficient without description. And I continue to work believing that for a writer like myself, who merely aspires to be strong, a good graphic may make a point about how a whole organization may be failing, or how a whole system may be improved, much more effectively than dozens of clumsily strung-together sentences.

I know I'm late with a couple of postings... I've just been caught up in end-of-the-year academica. I promise they'll be worth your while.

#10: What techniques help to minimize project time frames and maximize the chances for success? Why do they work?

At PieInTheSky, the rest of my teammates were some of the most talented people with whom I have had the pleasure of working. The wide array of skillsets, experience and insight were always astounding. But what always gave me the most pleasure out of my work with this group of people was everyone's ability to figure out, from the context, what hat they were supposed to wear for any particular project based on who else was there and what the actual engagement was about.
We worked so well together, in fact, that we managed to delineate a project planning process that helped us be both on time and successful. WARNING: I would hardly recommend for others to apply without validating it within their reality, as it depended on some particular personality . The process went something like this:

When a client called us over for a meeting to scope out a project for a new wireless or mobile solution, we'd first and foremost tackle the issue of why they thought they needed a solution in the first place. From there, each person would jump in with targetted questions that would give us a broad sense of the technical infrastructure that we would be dealing with. From there, we could set broad parameters to guide us in choosing a handheld platform and data transfer method from the enterprise data systems to the handheld devices. That was always the easiest part.
Once that was set, then we made every effort to bring in at least one or two of the end users who'd be tasked with using the actual widgets. This part was always the difficult part--for some reason, it's always hard to convince middle managers that the users need to be a part of the process.
From these discussions, we'd sketch out on a rapid prototyping tool what screens could look like, send it to the client manager, and got a general sense of yay or nay on the approach. This allowed us to not only get a sense of how many different screens we'd have to write but also how responsive the client managers were to our requests and updates.
It was only at this point that we set out a project plan with time frames, performance metrics, and a delivery schedule. Our schedules always included time for iterative development, testing, training, and final solution wrap-up. We also always delivered software that left our customers very pleased and that were on time and under budget.
How did we do this?
For starters, we had a good team. People knew how to fill in with their right roles as consultants, whether they came in as project managers, leaders, facilitators, doers or otherwise. We always made sure we had active involvement from clients, and that we were keeping them constantly appraised of our progress by sending them updated versions of the application. This allowed us to both get feedback on how we were tackling user interface issues before they became so embedded that it'd be a major undertaking to remove them, and also gave the client managers something they could show end users as it went along, showing them that there was in fact progress.
By the time that our clients rolled out the final solution, end users were already primed to accept it, almost excited by the prospect of not having to contact the call center every day or of having to print out those silly forms again.
In essence, our process gave the client manager a set of tools with which to demonstrate the transformative power of the mobile solution.

#9: Why might defining a technology change project be difficult?

As the newly-installed Manager of the Developer Program for a large wireless communications provider, I am in charge of ensuring that developers who want to build software using our handsets have all the necessary technical assistance to succeed. This is a fairly straightforward process: developers submit questions through a variety of mechanisms, and we respond to them with accurate and timely information or referrals to appropriate information sources.
In addition to that, I am charged with encouraging and promoting the further acceptance of my company's technologies as a platform for a variety of software solutions.
This last mission is the tricky one, as far as I am concerned, because I have two approach it from the perspectives of two very different groups: third-party developers and our company's own employees.
As far as I am concerned, this second mission is one large, cross-cutting process, with the successful output being a new adopter. I have a large set of tools at my disposal--a website, a functional technology platform, access to decisionmakers. Still, as a new person in this position, I face an interesting set of difficulties, while not emerging from a technology change project per se, reflect a similar set of dynamics:

• Defining an audience/set of users/interested parties: as far as I am concerned, my audience is theoretically anyone who works at my company, anyone who subscribes to our services, or anyone who has the skillset needed to develop software for our telephones. This makes defining who my clients are difficult because of my tendency to overreach.
  
• Defining internal stakeholders: while the company as a whole can easily be listed as a stakeholder in the success of the Developer Program, defining this in more narrow, operational terms is more difficulty. Are salespeople the stakeholders? Internal developers? Third party vendors? The marketing group alone? How much weight do each of these command?
  
• Getting upper management buy-in and institutional empowerment: I certainly feel like I have both the support and the authority I need to make decisions regarding the program. Certainly, and as is true with any other platform vendor, building a developer community is crucial to the success of the platform, and in our company the importance of the Developer Program is not under question. However, as would be with most operations that do not generate direct revenue but aren't considered traditional overhead, there is always a tendency to believe that the program must be justified.
  
• Selling the vision: tied to this previous piece of obtaining management buy-in is the necessary process of getting a consistent, constant message that data services are crucial to the company's survival. Certainly, there has been a message from the highest levels, articulated at the beginning of the year to senior management, that wireless data services are not only the future, they are also an essential tool for staying in business. However, from the initial orientation for all new employees to the way in which employees within the company see the company's offerings, it is clear that people aren't thinking, breathing, believing in data services yet. It is also somewhat apparent that the message that data is our future hasn't burned in yet. For example, we have a network and a service that far outstrips our competitors' offerings, yet the market perception is that our competitors have a superior offering--and not enough comes from our own information sources fixing that misconception. Selling a new vision in a large company requires an inordinate amount of repetition of the message, which involves a deliberate process of obtaining buy-in from a really large number of technology champions (to borrow Andrews' and Stalick's terminology).
  
• Establishing a strategy for transition when the other isn't really ending: It's clear that the company must shift from mere voice to voice and data services. However, the new technology and new way of selling doesn't come at the expense of voice--it comes in addition to voice. New ways of selling services do not necessarily replaces old ones--they supplement them. In that situation, the transition from an old way to a new way is very fuzzy and blurry, mostly because there doesn't seem to be a particular, determined "end" to the transition. At some point, people will be thinking data and operating with it in mind, but how can we establish the point of end? A certain sales point? A specific number of applications developed?
  

The definition of a change process requires dealing with personalities and people and their expectations. Getting people to accept what a new set of technologies will mean for how they operate and fulfill their daily functions is exceedingly tricky. Planning for the actual execution of a project (defining a team, a schedule, tasks, procedures, etc.) comes after having accounted for those people issues at some level.

Dorine,
Posting #9 is in the works... I'm still putting together my argument.

#8: What should organization leaders do to get people to accept new technology and the change it brings to their work?

The programming language used in software development represents not only a syntax for computer communication, but also a statement about programming as a profession itself. The vast majority of programmers I have ever worked with have an extensive set of justifications (rationalizations, even) for why their language of choice is better than the others and why it better fits with their thoughts on how the computing world should progress. In linguistics, it is understood that language conveys and perpetuates culture. An analogous understanding can be applied to the world of software development. Certainly, people have invested enough emotional energy in their programming languages of choice that the Language Holy Wars are not a strange term to most programmers. Not accounting for the reality that programmers' languages represent what we could call their Professional Culture is a recipe for the enterprise equivalent of the Chinese Cultural Revolution. Allow me to introduce yet another anecdote to illustrate my point.

Stale Headache Powder: the story of Fizz:

When PieInTheSky decided that it needed to develop its new platform for mobile services and solutions—let's call it Fizz—its architects, after much deliberation, decided that the Fizz should be built using Java 2 Enterprise Edition (J2EE) as a core foundation. There were a number of solid technical considerations involved in the choice of J2EE as the framework on which Fizz would be built: a large number of companies (potential clients of PieInTheSky) had chosen J2EE application servers for the hosting of their corporate websites, intranets, and enterprise solutions; J2EE offered a framework not controlled by Microsoft (as would have been the case with choosing .Net or COM); and, J2EE allowed PieInTheSky to develop software solutions without having to worry as much about the operating sytems on which potential clients had settled--J2EE application servers exist for all major (and some minor) operating systems.

The choice of J2EE, while solid on external, customer-driven grounds, left PieInTheSky with a technical conundrum: the vast majority of its engineering staff in various locations around the continent had been hired specifically for their strength in C++ programming and their knowledge of Microsoft client/server architectures and development methodologies. PieInTheSky's options involved either retraining everyone or letting everyone go and bringing in a whole new staff of J2EE experts. The latter being in short supply, PieInTheSky chose the avenue of retraining.

PieInTheSky's directors of software management decided that all engineers should be sent to an intensive J2EE training program, in which they would learn all they needed to develop the core components for Fizz. Aware that in order to keep their jobs they would have to become proficient in J2EE, the engineers dutifully attended their courses.

Still, 18 months after the extensive coursework and the huge company-wide shift towards Java from C++, Fizz was still not particularly fizzy. It was slow, bulky, and had more holes and missing pieces than one could count. Not only that, but a host of engineers left the company and a whole set of other engineers got laid off.

PieInTheSky's managers of engineering made two very significant mistakes:

First, they assumed that one can achieve fluency in any language in a matter of months with no immersion. One could assume, as did PieInTheSky management, that a good C++ programmer should have no problem picking up Java fairly quickly. Certainly, a good programmer can learn the foundations of any new programming language without much difficulty; however, the skills acquired in that short amount of time are usually insufficient for a large-scale, multi-tier client-server environment. This amounts to asking a six-month speaker of Russion to write War and Peace.

Second, management assumed that programming languages are as interchangeable as fuses in a fusebox or spark plugs in a car. As any speaker of more than one language knows, language carries with it much more than mere utility of communication. Each language has an essence, a je ne sais quoi that makes it distinctive. Sure, both Spanish and German have a word for "airplane", but how does one address the fact that "avión" evokes birds while "Flugzeug" literally translates to "flying thing"?

These two assumptions were not the undoing variables in themselves: the real damaging factor was that they did little to address the needs of engineers during the transition from one programming language to another. PieInTheSky's managers did much to sell to engineers the fact that the shift towards J2EE would represent something positive in terms of their experience and careers. They repeatedly made efforts at proving how this was a good thing for the company.

But engineers still had to cope with the fact that their many (or few) years of C++ and COM experience would become irrelevant. They had to deal with the fact that their investment in a Microsoft framework for software development would not give them any future benefit in the company--their performance would be evaluated on their J2EE strengths. Their world was being shaken from under them.

Yet management assumed that only with saying "this will be good for the company" things would be fixed.

Ignored went the declarations that "eh, it'll change again in 6 months". Ignored went the multiple angry departures of upset engineers. Ignored went the multiple bargaining efforts by some engineers to stay on board with legacy products built on C++.

What could PieInTheSky have done? Well, for one, it could have acknowledged that it was asking for a very large commitment from seasoned professionals to a new and risky vision. It could have acknowledged that the shift from Visual C++ to J2EE represented not only a change in language but a change in world view. It could have provided a mechanism for upset employees to ventilate their concerns without fear of adverse consequences. In short, it could have provided a longer-term set of support systems to assist engineers in dealing with the transitional period between "all C++ all the time" to "J2EE is the way to be".

Instead, it chose silence and unquestionable imposition. This was best summarized by the words of the President of the company, when addressing the staff after the first round of layoffs (only 6 engineers were let go that time): "we need everyone here to be fully on board, and if you're not then you should just get out of the way and let us go forward."

Those who presented valid objections found themselves "pursuing new opportunities" or "heading in new directions". Soon enough, those who had grievances learned not to vent them, but just harbored them in silence.

Eighteen months later, Fizz was still not complete, 350 more people were let go, and the grand plans for the software platform that others would buy for $5 million shifted towards an "internal development tool".