There was an interesting Twitter conversation today that touched on the importance of corporate communication to stakeholders about changes in policies, processes and technology. Although the thread was about Linden Lab's history with the Second Life user community, I noted that communication is almost always a challenge in software projects. Inara Pey asked if I thought communication was somehow harder when software is involved. I decided to answer here.Thoughtful, timely and consistent communication is critical whenever organizations act to change things stakeholders care about. We've all seen what happens when companies try spring changes on employees or customers without first getting them to buy-in: Negative emotions spring up, led by fear and anger; people act out in ways that undermine the change, either through active resistance or passive-aggression; and projects either fail completely or fall far short of their anticipated positive outcomes.
This cycle plays out repeatedly across organizations large and small. I've seen it myself dozens of time. Nevertheless, the people behind such changes are almost always unprepared for the negative response. They're surprised at the resistance (for which they take no responsibility).
To answer Inara's question, software projects pose all of the communication challenges of non-technical projects and add a few significant ones of their own. The main complication is that the technical people delivering the solution don't have a holistic understanding of the user's perspective. They can move through a list of requirements with perfect execution, but end up with an end-product that people hate. So there may be some usability issue that is obvious to an end-user, but invisible to a developer or executive. For instance, the initial design of Second Life Viewer 2 (or was it Viewer 3?) when the menu interface blocked a quarter of the screen.
- Consider the point of view of the people who will be impacted by a change
- Remember that there are probably multiple stakeholder segments with unique needs
- Engage them in the process from the initial decision-making through project completion
- Enlist the active support of people who are influential and respected
- Provide the education and support needed to adapt to the change
1 comment:
My question was more, "Why do you think software projects are more difficult to communicate than other technology-lead / technological projects"; as there seemed to be an implication (perhaps misplaced on my part) that software projects were harder.
To me, all technology-lead / technological (any complex / specialist project for that matter) actually have the same degrees of difficulty in communication.
As to Change Management: again, this is not restricted to software alone - although granted the IT industry has potentially gone more to town in developing processes to deal with it than elsewhere (re: ITL, CoBiT, MOF et al).
However, in any issue of change, the fundamental issues are the same. Indeed, with regard to SL in particular, it is a subject I blogged on myself myself some time back in response to an article by Hamlet Au. (See: http://modemworld.wordpress.com/2011/03/18/change-in-second-life/).
As such, I see nothing particularly more complicated where software is concerned than I do with any other complex environment.
What it really comes down to is a company's willingness to accept that there is a need to move in a specific direction in order to make itself better understood (although granted, where LL is concerned, there are unique user-driven complexities, but these really form the basis of a far broader discussion, again as I touched upon in my response to Hamlet).
Post a Comment