Envisioning and shaping the future of work and business.

Thursday, June 28, 2007

My Wish List to Google Contains...

3:22:00 PM Posted by Oscar Berg , No comments
...single sign on to all the Google apps that I use (currently Gmail, Blogger, Docs & Spreadsheets, Google Reader, Google Calendar, Google Toolbar, Google Groups, Google Talk, Google Analytics, and Picasa).

...a unified interface design that is consistent across applications and a control panel or navigation bar (Google Toolbar?) that easily lets me toggle between all my Google apps.

...the possibility to have a local repository for backing up and accessing all my content offline (Google Gears will do this?).

...a unified search that enables both public searches (Web pages, documents, images, people, products, books, blogs, papers etc) and private searches (documents on the desktop, gmail, calendar events, contacts, docs & spreadsheets, notes, blogs) from one single search box.

...tagging of any kind of content item (tags are of course shared accross applications) and an interface where I can easily manage all my tags.

...the contact list with Google Talk as an integrated part of all applications with the possibility to drag-and-drop content items to the contact list to share them with my contacts, and to drag-and-drop content items from a conversation or e-mail to work with them (or store them) in the proper application.

...an explorer interface where all my content items are available (such as the one used for Google Docs & Spreadsheets) and can be browsed and filtered by tags and others metadata such as content type, author, importance and creation date. With versioning of all items and the possibility to share and discuss them with any user I invite.

Wednesday, June 27, 2007

Some Comments on Team Collaboration and Project Management

Project management is about getting the right people to collaborate as efficiently as possible in order to achieve a common goal - on budget, in time and in line with (or, if possible, above) expectations.

It surprises me how many organizations seem to believe that project management is first and foremost about making budgets and time plans and how little effort they actually spend on creating a sound collaborative environment for their projects, even when they are using remote (virtual) teams. Project managers should not be seated in front of their laptops to create time plans and budgets with a project management bible in their lap. Instead, they should try to create an environment for their projects that fosters efficient communication and collaboration. With that in place, they can focus on defining and clarifying the goals and main deliverables of the project, finding the right people and making them connect and get to know each other. After having defined what the project is to achieve and what resources are available to it, the project manager should use the time constraints and budget to shape and trim the project.

As a project manager, it is essential to try to understand what is needed for achieving efficient collaboration within the team and with project stakeholders. James Dellow points to the following collaboration challenges for remote teams in a post about Collaboration challenges and success factors:
  • "Willingness to collaborate (driver by a combination of necessity and opportunity);
  • That all the people involved have the right collaboration skills; and
  • Having access to and selecting the right information and communication technologies (ICT)."

He then presents the following critical success factors for creating a sustainable virtual team:

  • "Control - does the team have a clear sense of direction and progress towards their objective;
  • Enabling Resources - this includes providing people with time to collaborate, funding for travel when required, people to provide support and also the right work environment and facilities, etc; and
  • Communications - extra effort is required to supplement the social capital that is created naturally in a co-located team through a combination of formal and informal communication."

He continues with making this important point:

"Underlying these challenges and critical success factors was the point that all these issues that can be managed, but often required forward planning (through a start-up or refresh process for existing remote teams)."

It is clear to me that a lot can be done to create an environment that can foster efficient communication and collaboration for projects, and that providing access to the right collaboration technologies is a big part of that work. In a post about team-based project management, David Coleman gives this simple and powerful example of how the proper use of collaboration tools can shorten the project execution time:

"Imagine you’re a contributor on a project and you are in the project space looking at a document and you have a question for one of the authors of the document. Today, the mechanism to deal with this is e-mail. You have to flag the document. Possibly highlight the area in question, and then e-mail your question to the author(s) in question, a process that could take days!

Now imagine the same scenario, but you had IM and Presence Detection integrated into the project software. You could see that one of the author’s is on Yahoo Messenger, you can ping them, ask your question, make the change to the document, and be done in a matter of minutes instead of days .

This is where RTC (real-time collaboration) tools really shine, in facilitating the interactions between those in a project, not cutting the task time down (although that may occur also). If you look at how the work really gets done on a project, it is the time in between the task work that really kills your schedule. If some of that inactive time can be made productive and cut way down, then the whole project will move faster."

Organizations that execute a lot of projects with remote teams should not hesitate to embrace Enterprise 2.0 technologies such as wikis, blogs and real-time communications and find out where and how these can contribute to a more efficient environment for communication and collaboration.

Tuesday, June 26, 2007

Approaching Information Quality

Information quality is often a neglected topic, both from the business side and the IT side. Perhaps, it is because information quality is a complex concept that includes many management techniques and quality practices.

Neglecting information quality issues may e.g.:

  • lead to extra time and resources to manage and resolve information assets
  • initiate a loss of credibility in services
  • delay deployments of new applications and integrations
  • be an originator of compliance problems
  • cause customer and partner dissatisfaction

When starting a quality effort it is often necessary to manage issues from two sides - existing quality issues needs to be sorted out and the occurrence of new issues needs to be minimised.

A quality study often reveals many existing and often serious quality issues. One of the things to deal with is simply where to start hence the actions need to be prioritised. A successful approach can be based on an evaluation of information assets (where quality levels are compared to business importance) and a shortlist of actions (selected by comparing business benefit to business effort).

Realising the actions often requires buy-in from sponsors and stakeholders. The approach is more solid if it can be supported by a business case. The business case should clearly state increased costs and risks as well as possibly lower revenue and confidence. The quality of the business case itself is reliant on e.g. how well the information assets are linked to IT services and business processes.

Minimising the occurrence of new issues may be done at different levels depending on the ambitions of the sponsors and stakeholders. Below is a list of some common actions to consider for the long run:

  • Create a information quality strategy to define a practical quality approach and a realistic vision
  • Establish a governance of information quality to unite business and IT professionals
  • Define appropriate metrics & tools for business focus and results
  • Assess master data and information architecture to deal with inconsistencies and sharing problems
  • Realise an information quality process and instructions to enable continuous improvements
  • Manage awareness and change concerning quality work to secure implementation

A common misconception is that quality is owned by and the responsibility of one group. However, a successful quality effort should lead to the realisation that quality is, and should be, the responsibility of everyone.

Friday, June 22, 2007

What It Means To Know The Business, The Technology And The People

12:04:00 PM Posted by Oscar Berg , No comments

I felt a need to elaborate a little on my previous post “Three Questions to Answer Yes to Before Starting an IT Project” where I argue that the probability of project success depends on how well you know the business, the technology and the people that are to be involved in the project. So here are a few examples of how it will help a project manager to make the project successful.

When you know the business...

...you don't have to spend a lot of time and energy on learning and trying to understand the business
...you can avoid misunderstandings since you have enough knowledge about the business context to interpret what stakeholders really want
...you can focus on the goals and deliverables of the project
...you know the politics of the organization and can hopefully manoeuvre the project to avoid major political conflicts
...you know who actually makes the decisions and can anchor the project and requirements with those stakeholders

When you know the technology...

...you know what skills to require from your team members
...it is likely that the technology is mature and proven and thereby less like to cause problems to the project
...the capabilities and limitations of that technology are well known which makes it easier to capture realistic requirements

When you know the people...

...you know what they are capable of and can put together a team that has all the capabilities you need in the project
...people tend to compensate each others weaknesses and complement strengths
...you don't have to spend a lot of hours and energy learning to know each other
... territorial pissings and conflicts within the project team are less likely to occur
...you know how to communicate with each other and can focus on communicating what is necessary instead of everything

If the business, the technology and/or the people is unknown to you or any of your team members, then you know where to expect problems and can focus your risk management efforts in these areas.

Thursday, June 21, 2007

My Recently Starred Items

7:32:00 AM Posted by Oscar Berg , , , No comments

Here are a few RSS items I have starred recently in Google Reader:

Seven Reasons for Your Company to Start an Internal Blog
How you can put e-mail to shame with internal blogs.

Personalisation vs segmentation
A comment on the overuse of the term personalization.

A Short Definition of "Strategic Planning"
A nice and brief description of strategic planning.

Enterprise 2.0: Making the Business Case
Voices from the real world on Enterprise 2.0 and collaboration:
"Before everything was done in an isolated way within individual business units, but now what we learn is applied enterprisewide so we can save money," said Volvo's Carole Boudinet.

Wednesday, June 20, 2007

The Need For Content Governance

12:54:00 PM Posted by Oscar Berg , , 3 comments
I think most people who have worked with content management in an organization have experienced the following:
  • Content products are developed and produced but never or rarely used
  • The content that is produced is not always accurate, complete and/or timely when released
  • Content defects are not discovered, managed and resolved in a structured way once the content has been released
  • The efficiency of content products is not measured
  • Content products becomes outdated but are not archived or retired
  • Content is not maintained and updated
  • Content products do not comply with branding standards and guidelines
  • Content does not comply with laws and regulations
  • Content falls into the wrong hands and get
  • Taxonomies grow wild and become inconsistent and more or less unusable over time
A lot of the content within an enterprise is of great importance or even critical to the enterprise and should therefore be managed with the same respect as other kinds of assets. The reason is, simply speaking, that bad content quality can hurt the enterprise badly. Despite this, many content workers seem to put their faith into technology and simply assume that content will automatically remain complete, correct, fresh and relevant once they have produced and released it. Or even worse, they don't care what happens to it after it has been released the first time.

I have experienced this many times. Often it has to do with the fact that the people that produced the content are no longer responsible and accountable for the content. The content was produced and delivered by a project and then it was left to its own devices once the project closed. If the project deliverables were handed over to someone before the project closed, it was probably handed over to someone in an IT maintenance organization, an organization that was set up to maintain and govern IT solutions – not content. Having the wrong person responsible for managing the content is often worse than having no one responsible for it, because then people tend to believe it is managed when it is not.

So how do you avoid this? Well, first of all it is absolutely essential to have disciplined and skilled people that have the right attitude. This is by far the hardest part. If you are failing here, especially if people's attitude is wrong, then your chances of succeeding are small if not minimal. But if you manage to get disciplined and skilled people with the right attitude by your side, then it is just about establishing and implementing a functioning governance model and getting the right processes, resources, tools and infrastructure in place to manage the content throughout its life-cycle.

When discussing governance models and frameworks, it is important to understand that there is no single model or framework that will suit all organizations. Besides that no organization and enterprise is identical to another, it is often hard to draw distinct lines between different areas of responsibilities. For example, it is hard to draw a distinct line between the management of internet-specific content, intranet-specific content, documents and digital assets. Consequently, it is a better approach to define what needs to be done and what resources and roles are needed to do the work instead of finding a model for how to organize these roles. It is also pretty simple to identify what needs to be done to get well functioning governance, such as:
  • Management support
  • Policies, standards and guidelines to follow
  • Functioning processes
  • Clearly defined roles and responsibilities
  • Skilled and disciplined people with the right attitude
  • Supporting tools and infrastructure
  • Routines for auditing and follow up

It is nice to see that so many organizations are getting better and better at governing their IT business. Now they just need to set the same level of ambition for governing their content.

Monday, June 18, 2007

Documenting the Design Rationale Behind a User Experience Design

11:27:00 AM Posted by Oscar Berg No comments
Many of the user experience designers I have worked with in web projects have been very skilled and experienced. Even so, I have rarely encountered a designer who has explicitly documented the rationale behind the design - why a certain design decision was made, what alternatives that were considered and why they where discarded during the design process.

Documenting the design rationale can be as simple as providing some pros and cons together with each design sketch and then recording which design sketch was chosen and for what reasons. If any changes are made in-between two sketches, those should of course also be described and motivated.

One of the main benefits of documenting the design rationale is that it is easier to anchor the design with stakeholders. Besides that the designer probably will have to think through the design suggestions more (which will probably lead to a better design in the end), it also forces stakeholders to motivate both their decisions and any critique of the design suggestions. Simply put, it will be easier to discard all those personal opinions (“I want to have the button there”) that are a nuisance in most design processes. You simply point to the common practices, best practices, usability heuristics, guidelines etc that you have motivated the design suggestion with. It will move you faster to a final design and can radically shorten the design process.

I have twice in my career experienced how someone in the upper management has suddenly intervened in the design process and decided to change from one icon to another. I don’t know if it is common that managers possess special skills in icon design and usability or if these situations really can be avoided by documenting the design rationale, but at least decisions like these will be documented with why and by whom the decision was made. As motivation behind the design decision it will probably have to say “Because manager X wanted it”.

Thursday, June 14, 2007

Making the Complex Clear

7:15:00 AM Posted by Oscar Berg , No comments
As an IT professional I see it as one of my main tasks to make complexities clear to business people and other stakeholders that are making or influencing decisions about IT in an enterprise. With this I mean primarily two things:

1. Making complexities easier to understand
2. Revealing unnecessary complexities

After this has been done, it is easier both to reduce and manage complexities, as well as establishing the proper IT/IS strategies, improving processes and making the right choices on IT investments.

However, it is important to understand that complexity does not need to be a bad thing, it just needs to be at the right place. In fact, increasing complexity is required for making a business more agile as well as increasing cost efficiency by enabling reuse and faster modification of IT solutions. Besides having complexity at the right place, there needs to be predictable patterns behind it, and it needs to be based on explicit and well established principles and rules.

The increase of unnecessary complexity is definately a maturity thing. By applying a coherent architectural strategy, using design patterns, enforcing standards, establishing and exchanging best practices, and consolidating heterogonous environments unnecessary complexities will be reduced. It is my strong recommendation to anyone dealing with IT to make Einstein's "Make everything as simple as possible, but not simpler" to their mantra. Because in the IT industry we tend to overcomplicate things, add unnecessary complexity, and not care enough about following principles, patterns, standards and guidelines.

To make necessary as well as unnecessary complexities clear to business decision makers is a challenging task for IT and management professionals. But there simply is no escape for businesses - making the complex clear is an absolute necessity for making the right business decisions.

Tuesday, June 12, 2007

Three Questions to Answer Yes to Before Starting an IT Project

2:21:00 PM Posted by Oscar Berg No comments

In my (work) bookshelf there is a book called “Project Secrets – Making Things Happen” by Donald Davies, co-founder of Donald Davies & Partners and project / program manager with over 50 years of experience from the IT industry. I have met him in person and even discussed becoming a partner of Donald Davies & Partners a few years ago, but I had other plans at the time (such as leaving Stockholm). Anyway, his book contains a lot of thoughtful reflections, experiences and valuable advice from his incredible long career and I particularly like his advice “Avoid three new things at one”, which goes like this:

“It is difficult to:

  1. be a new and unknown company
  2. enter a new market
  3. introduce new product

If all three occur at the same time the chance of success is low, so entrepreneurs should not attempt it unless they have plenty of cash, enough experience and knowledge to make it happen, and time enough to meet the window of opportunity.”

I find this to be very true. The advice made me think about what needs to be fulfilled to start an IT project and here is what I came up with:

Don’t start or accept to be assigned responsibility of a project when you are in a situation where you have to answer no to all of the following questions:

  • Are you familiar with the customer and/or their business?
  • Are you setting together a team with known people?
  • Are you planning to use a known and proven technology?

I certainly have managed a few projects where I would have had to answer no to all of these questions if someone would have asked me. I am also completely sure that these projects made me go (almost) bold. Fortunately, I have learned a lot from these projects, such as simply not accepting responsibility for a project where I cannot answer yes to at least one of the three questions above. But was losing my hair a feasible price for learning that lesson? No.

Monday, June 11, 2007

A Train Of Thought

Information is the result of a successful communication process. Technically speaking, a message has been sent from a sender to a receiver who has interpreted it successfully. A communication process can also transmit experiences (compare a time table vs an artwork). It can of course transmit both information and an experience.

Content is the vehicle with which information and experiences travel in the digital world. A sender (producer) creates content to transfer the information and/or experience to the receiver (consumer). The information and/or experience is created by cognitive processes in the head of the receiver when the content is perceived and interpreted (or experienced).

Knowledge is applied information. It is created when the receiver has understood and reacted on the information.

Data are small pieces of content that need more context to transmit something of value to a knowledge worker. A small piece of content (datum) need to be put together with other pieces of content to get more context. By aggregating data and presenting them in spreadsheets or diagrams, them can communicate how a business is performing and help to make business decisions (Business Intelligence). But alone, these small pieces of content are practically useless.

Enterprise Content Management (ECM) is about efficiently and securely producing, managing and delivering content within an enterprise context. The purpose of the content can be to transmit information and/or experiences. If delivered to the right person in the right time in the right way, it can create the proper reactions and generate (transfer) knowledge.

Until now, ECM has primarily focused on unstructured content. However, it is reasonable to suppose that it will also extend to including production, management and delivery of structured content (data) in the future. By combining delivery of structured and unstructured content and prodividing collaboration tools to facilitate collaboration, knowledge workers will be able to make informed decisions together and increase their productivity, efficiency and innovation capacity.

The overall approach for aligning structured and unstructured content and delivering the right information (or rather content that transfers information) to the right person in the right time within an enterprise is Enterprise Information Management.

Sunday, June 10, 2007

Enterprise Information Management Components

Information Management is a concept that is relatively well known. Recently the term Enterprise Information Management (EIM) has become popular. EIM initiatives often support a wider range of services and information, are guided by a strategy and driven as a program across business unit borders.

Many people feel it is a daunting task to set off an EIM initiative. How to kick-start and scope a strategy or program? Below is a list of core components to consider with some basic definitions (back-end enterprise applications and other information sources are not included):

Interaction oriented components

  • Enterprise Portals: Delivery of digital content in multiple channels
  • Self-Service Applications: Automated business transactions initiated by users
  • Business Intelligence: Gather and analyse data for business decisions

Information oriented components

  • Enterprise Content Management: Production of content for any media
  • Information Quality and Integration: Correct and combine information from applications
  • Master Data Management: Manage and consolidate shared data

Integration oriented components

  • Business Process Management: Model and manage business processes
  • Service-Oriented Architecture: Making IT easier to reuse and integrate
  • Enterprise Application Integration: Transport and transform messages

Discussing business needs, issues, stakeholders, projects, providers etc in relation to the components above has proven itself a good way to get many EIM efforts going.

Tuesday, June 5, 2007

Business Agility and Efficiency make the Business Case for BPM and SOA

To meet the challenges of a fast-paced global business environment, an enterprise must be able to change rapidly. And to be able to do this, it has to become more agile. On the other hand, the enterprise also needs to become more efficient so that it can respond to the pressure from competition and shrinking margins in a global economy. This very simplistic illustration is meant to illustrate how the gaps between the business environment, the business processes and the IT systems are increasing over time in many enterprises due to the inability to quickly respond to external and external changes.

Becoming agile means that the enterprise must be able to keep itself together and avoid any gaps between the business environment, the business processes and the IT systems. Efficiency, on the other hand, is about streamlining, automating and optimizing processes and removing redundant processes. Efficiency is also about becoming better at reusing IT investments and making sure that when the business is trying to respond to changes, the IT systems can easily, and at reasonable cost, be adapted to support those changes instead of becoming obstacles.

Enterprise Architecture (EA) is a practice of describing the current and desired state of processes, rules, resources, roles, organizational units and information systems within an enterprise, with the overall goal to align them all with the objectives and strategies of the enterprise. Common requirements that modern enterprise architectures are supposed to handle and support are increased agility and efficiency. This also explains why BPM and SOA has become so widely adopted by enterprises:

  • Business Process Management (BPM) is a field of knowledge combining management expertise with information technology capabilities that guides on how to model, design, implement, govern, measure and analyze operational business processes so that they align with business objectives and strategies, but also so that processes can be streamlined, automated, optimized for performance and/or removed if being redundant.
  • Service Oriented Architecture (SOA) is an architecture for information systems that is based on the concept of service-orientation. This means that information is made available as a service for anyone to access without knowing the underlying implementation. An IS architecture with these qualities is well suited for aligning existing and new information systems with business processes, while at the same time being able to meet business demands for flexibility and cost reduction.

So, agility and efficiency is the two main drivers behind BPM and SOA. I hope this post provided some context to these abbreviations.

Monday, June 4, 2007

Expensive Things Must Look Advanced

12:32:00 PM Posted by Oscar Berg 2 comments

I once (in the late 90ies) helped a Swedish insurance company to design the UI of a workflow application for managing insurance cases. The application was integrating and adding workflow functionality to a number of legacy systems that had text based UI:s. The users were required to toggle between them when performing a task and the workflow routing was completely manual.

After having demonstrated a prototype of the new UI for the steering committee by walking through an entire workflow scenario in only a few minutes, I got the evil eye from the project sponsor who irritated asked me “Is that all?!” “Eh…yes, that’s all” I said, wondering what I had said or done wrong.

I was surprised at his reaction since all of the users who I had involved in the design process had been very happy with the results. It clearly simplified their daily work, not the least it reduced the cognitive load of having to remember information when toggling between applications. It also significantly reduced the time to complete an entire workflow, which was exactly what I demonstrated for the steering committee and project sponsor. But the project sponsor expected to see some evidence of where his money had gone, which I obviously had failed to show him.

I can understand how he was thinking – if you pay a lot for something, then you generally expect it to be advanced (meaning complex), especially when it comes to technology. If it looks really simple, then you are likely to feel ripped off. Where did your money go? To social activities of expensive consultants?

This way of thinking is also the reason why many CIO/CTO:s get dazzled when software vendors are showcasing their advanced (complex) new products or showing PowerPoint presentations about them that are stuffed with 3D boxes, arrows and abbreviations. As a software vendor, you simply cannot sell the latest version of your product to anyone by telling them it has been greatly simplified and that you even removed some of the old features so that it gets more efficient to work with. No, efficiency in the IT industry has since long (since ever?) been synonymous with adding new and more advanced (complex) features. If a vendor would actually simplify a product, then they would instead have to point to all the new and advanced under-the-hood technologies that have been named with mysterious three-letter abbreviations.

I know this by now - simplicity does not sell. Of course, most users like simple and easy to use applications once they start using them. But before they start using it, someone probably has to pay a lot for it. And it needs to be advanced (complex) if that someone is going to buy it. It is as simple as that.

Sunday, June 3, 2007

Why SaaS is an Attractive Software Delivery Model

9:53:00 AM Posted by Oscar Berg , No comments

A few years ago, I was product manager for an ASP application called Spirello Express for creating and maintaining web sites. It was offered as a service for a small subscription fee and targeted specifically small businesses. By today's standards it would definitely have qualified as a SaaS application since it was developed as a web application by a software development company with expertise in modern internet development technologies such as XML, XSLT and Web Services. Even though the service was hard to sell at the time for various reasons (such as low interest in the web among small businesses), I found the SaaS software delivery model to be very attractive and having great potential. Here are some of the things I liked the most.

  • You can build a user community to get feedback about the service and its features and easily ask about desired enhancements.
  • There is no real need bundling a lot of features and enhancements into big releases, given that the current software and interface design is scalable and that the service does not have to be changed in its foundation when new features are added. Instead, you can continuously release new and enhanced features in a way that goes along very well with iterative and incremental software development processes. It also lets you respond to competition faster that with traditional software delivery models.
  • You can sneak out new features and enhancements under the "beta test" cover and let your users evaluate them to determine if they add value or not and what enhancements to make.
  • You (eventually) learn how to deploy changes to a live environment with a minimum of disturbances for your users.
  • Finally, the user experience needs to be intuitive because you don't have the option to force your users to read comprehensive manuals or attend training courses.

The main headache for us was the unpredictable availability and performance of the service. It was hosted by a small hosting company from which we bought capacity and we had no real control of the environment. It could suddenly go down without us being made aware of it by the hosting company. We should have hosted it ourselves, but were too small as a company to afford that investment at the time. I thing Google and many other SaaS providers are doing the right thing in this respect - they own and control the environments in which their SaaS applications are hosted.