Open and clear communication is often a key success factor in the execution and delivery of projects of all sizes. Yet, we not always give it the attention it deserves. The guidelines below are particularly useful in raising communication awareness with newer team members when taking up new assignments or projects.
Leave a Comment » | 
Chart, General, Project Management | Tagged: Communication, status | 
Permalink
Posted by ornot
After starting to follow and participate in the innovation conversation, my impression is that, aside from its share of buzzwords, more often than not, the conversation appears to be happening inside an “innovation bubble”.
As a technologist this is, unfortunately, familiar territory as it reminds me of the “technology for technology sake” trap that many large and also small companies fell victims of.
When we talk about innovation as if it was its own entity without giving serious consideration to the core business and commercialization dimensions we are doing the same thing.
Today, innovation, as well as technology, should be part and parcel of our core business and the way we work. Not an appendix. Definitely not their own bubbles.
Some companies do get it. This is what I found particularly inspiring when I had the chance to listen to Peter Aceto (@CEO_INGDIRECT) from ING at the Business Innovation Summit. For them business, technology and innovation appear to be one thing. They also talk very clearly about the increasing need for transparency.
For business, technology and innovation to be a part of a single vision and execution, we need a platform of transparency to build upon. Without transparency between departments and with the public, it’s much harder to get off our bubbles.
Leave a Comment » | Collaboration, Innovation | Permalink
Posted by ornot
The inability to iterate is a recurring characteristic of most large companies I worked with, and in my opinion is one of they key obstacles they face to allow innovation to occur. This becomes particularly visible and painful when solutioning for complex problems, to which the answer is not readily known.
The second characteristic that appears to go hand in hand with the first one, is that they all have a discourse of becoming more agile and innovative – even though all their processes, actions and funding models are geared towards the “build once & deploy” paradigm. There is obviously a gap between the desire to produce innovation and the infrastructures in place to support it. Under these structures, these companies become, at most, good at delivering against predictable problems – problems to which solutions are relatively evident and can be planned from back to be start. Although this is a great skill, it will not help the company successfully tackle complex problems that require innovative solutions.
This is one of the key reasons these same companies typically have less than ideal intranets and collaboration systems – because these are problems for which the use of the “build once & deploy” prescriptive solution approach will typically fail.
Allowing for iterations should be viewed as a strategic element for creating a sustainable ecosystem that suports innovation.
Leave a Comment » | Chart, Enterprise 2.0, Innovation | Tagged: Creativity, Innovation, Iteration | Permalink
Posted by ornot
In large organizations it is not difficult to start spending considerable amounts of money in projects that are making little or no progress. This eventually becomes painfully visible at certain stages at which point the project receives a great deal of attention as the organization collectively pulls together to bring things back on track and put the monster it created to bed.
Aside from the obvious “sub-optimal” use of company resources this process creates two side effects: (1) it generates an internal lack of confidence in the organization’s own ability to deliver (2) at the same time creates pressure to demonstrate that the organization can.
That pressure manifests itself in different ways. A common pattern is to create a sense of urgency in the teams to move things along quickly and hopefully produce visible results that will reduce the pressure (aka lighting a fire under the team). Unfortunate this rarely works when the underlying problems still persist.
The most common underlying problem I have seen in my consulting career has been a very simple one: lack of clarity on approach and on roles and responsibilities. Someone told me once that “simplicity is elusive”; and that is very true. In fact, it may seem simplistic to blame the creation of a monster on two things, but we need to consider the negative cumulative cascading effects that they create – particularly when accelerated by that sense of urgency we lit under the team (even though well intentioned).
The reality is that without a clear approach and the basic project structures in place we become like fire-crackers going in circles spending a lot of energy and money to move very little ahead as opposed to being that rocket with a clear and common target in mind that we wish we were.
It sounds simple, but the key is not get yourself dragged into the fire-cracker pattern in the first place because once you start not only you don’t get anywhere but you eventually also drag your most talented people to be fire-fighters running along trying to tame the monster and extinguish the fires we lit in the first place. Meanwhile, the next monster is on the works on the periphery of our radar.
Luckily, it is amazing how much of a difference it makes to do two things before you move too far: (1) have a solid and well articulated approach and (2) clear roles & responsibilities.
1 Comment | Project Management | Permalink
Posted by ornot
Maintaining alignment requires constant attention to detail and to communication.
I don’t recall where I captured this simple and very nice drawing… I find it very useful to remind us of the importance of maintaining alignment.
Leave a Comment » | Chart, Project Management | Permalink
Posted by ornot
[DRAFT]
Often software development projects go off the rails or deliver a low value end-product. Budgets are not getting any bigger and teams are trying to deliver more efficiently using various techniques. One of my favorite technique is to find the things that you don’t have to do before it’s to late (and we have already lost time and money doing it). This is based on the premise that most if not all software development projects include a number of things that do not need be done at all, and many that can be simplified or adjusted and still deliver the same business value. I have yet to find a project where there were no features, sub-features or technical tasks that could be avoided. One of the reasons this happens has to do with how most software requirements are defined: they are defined without much critical dialogue between business and technology. Therefore, in many cases we end-up missing on the opportunity to shape a product that is technically simpler with high business value. Developers that at some point receive the “spec” feel far removed or simply don’t bother to question a requirement that is complex to implement and just go ahead and develop complicated solutions that are not necessarily required by the business or could be easily adapted to suppress or significantly reduce complexity. Multiply this again and again during a project and you have a lot of missed budget saving and complexity management opportunities.
As a developer using this approach, I remember that one of the things that surprised me was the cumulative effect that simplification can have. Once you save a day or two by not doing something, all of the sudden you have that extra time (or part of it) to “freely” analyze other tasks to find more efficient ways of delivering them or perhaps avoiding them altogether. The later has the potential of giving you back large amounts of time/budget but are not always evident and often require that extra bit of time to allow an insight to surface or a new idea to be tested. We normally don’t have that time, so we need to create it ourselves. Furthermore, finding these opportunities to save time is very important particularly because the opposite is guaranteed to happen: you will always find things you did not anticipate or have budgeted for that you will need to deal with. Most projects have contingency buckets that are designed to help with this problem but those are also getting very modest.
Unfortunately, this avoidance strategy is underestimated or ignored by many as they think this is the same as simply cutting scope – which they are afraid will not be well received by their customers or stakeholders. This is a misconception, as the process of identifying, questioning and negotiating complexity will often lead to better software. In many cases the time we save by not introducing unnecessary complexity can be applied towards enhancing the product in high value areas.
1 Comment | General | Tagged: Complexity Management, Project Management, Software Development | Permalink
Posted by ornot
With the ever-growing sea of digital information within and outside our organizations, comes the natural need to be able to navigate through it all and find what we are looking for – or even better, have the right information find us. The power law that most of us are used to in the context of e-commerce also applies directly to search. The curve below is typical of any search application, showing a high concentration of “hits” on the most popular keywords followed by a very long tail of low hits (down to one time queries).
Understanding this behaviour is important in order to optimize and tune the search experience, as specific tools and techniques are available to deal with the different sectors of the curve. While the “head” is prone to manual intervention allowing content managers to bias known results to ensure higher relevancy, the “tail” is where more sophisticated search platforms can make a difference by surfacing the otherwise buried information in ways that provide insight to the end-users. A good enterprise search experience will, among other things establish a conversation with the user helping him or her navigate and drill down to the right information.
Below are some of these techniques, from an imason enterprise search presentation.
1 Comment | Chart, Enterprise 2.0, Search | Tagged: Long Tail, search experience, search tunning | Permalink
Posted by ornot
Often in SharePoint 2010 implementations we see Portals, Team sites and Social sites being treated as separate conceptual entities. Although they have their own merits and add specific value individually, it is in “the intersection” where we find the ideal balance of flexibility, context and business alignment for open collaboration. Furthermore, in the intersection, the user experience allow us to easily flow between the different spheres and levels of formality.
Related post: Collaboration Atmosphere – chart
7 Comments | Chart, Collaboration, Enterprise 2.0, Visualizing Information | Tagged: collaboration, Diagram, Enterprise 2.0, intranet 2.0, KM, Knowledge Management, SharePoint 2010, social intranet | Permalink
Posted by ornot
In the analogy, think of how the high gravity that exists closer to the sun and how it affects movement. The closer to the center the more rigid and formal everything is. By the same token, the further from the center, the more loose and disconnected things are.
Related posts: Content Management Formality Spectrum & Social Network – The Intersection Diagram
1 Comment | Chart, Collaboration, Enterprise 2.0, Visualizing Information | Tagged: Adoption, collaboration atmosphere, e20, formality spectrum, intranet 2.0, social intranet | Permalink
Posted by ornot
I am enjoying reading Andy McAffe’s “Enterprise 2.0” book. Here is a bull-eye type chart illustrating the SLATE concept (Search, Links, Authorship, Tags, Extensions, Signals) that summarizes what he calls the “Emergent Social Software Platforms” (ESSPs).
Leave a Comment » | Chart, Enterprise 2.0, Visualizing Information | Tagged: Andy McAffe, collaboration, e20, Enterprise 2.0, intranet, SLATES | Permalink
Posted by ornot
... or not 
