While working technology selection projects, one feature that I like to look at is flexibility. In the past, flexibility wasn’t exactly a feature that was touted by many vendors, but in recent years, we’ve seen more folks highlight their solutions as being flexible, customizable and able to do multiple functions for a business.
Flexibility – if designed and implemented correctly – is ideal for technology solutions and is wonderful for IT groups since we are constantly being asked to do more with less. Flexibility allows IT groups to choose solutions and approaches that best fit their current needs and best prepare for their future needs. Building solutions that are flexible is good business. It is good business for the vendors and good business for IT groups.
There will always be a need to replace some systems as an organization evolves, but selecting and implementing a solution that can change and evolve over time helps the business grow more efficiently without having to replace all systems regularly. Solutions with flexibility as a feature allow organizations to focus their time and resources on growing the business, not changing out systems and solutions every few years.
One of the best examples of flexibility as a feature can be found in cloud computing. When I use the cloud, I can design a solution that uses best-of-breed today and be confident that i can easily replace and tweak the systems in that solution as needed moving forward. When I need more processing power, I push a button. When I need more storage, again…I push a button.
Compare the above to on-premises systems. You can’t quite just push a button when you need more processing power or storage…you have to find more hardware, install it and add it to the system (or re-purpose other hardware in your data center). The same is true for storage…you may have plenty of storage today, but what about next year? How will you add storage to your already full data center?
Flexibility as a feature is what every CIO and IT Professional is looking for today. We are being asked to do more with less and need to be able to use our systems and solutions in different ways as we grow and change.
Is your organization looking for ‘flexibility’ as a feature set in your technology selection projects?
I’ve been playing around with the idea of User Personas for use in technology selection projects. I’ve used user personas while building various websites and applications, but never used them (or heard of them being used) in technology selection projects.
Again – I’ve mostly run across personas in the web space as a way to help guide/drive design of websites and content. I have used user ‘scenarios’ before in selection projects but never taken the formal step of creating personas.
In my thinking about the subject, I’ve come up with a few positives outcomes of creating personas for selection projects. They are:
Thinking about personas forces you to think about the people first. What type of people will use your technology? How will those people interact with it?
Personas force you to roleplay and gameplay your technology strategy. While thinking about user personas, you are forced to walk through your strategy and technology roadmap to ensure it matches your organizational culture.
Personas can help you think through support requirements for the new technology.
Now…most of the above are things that any good team and/or consultant should do anyway…but by focusing first on the users and user personas, wouldn’t it force to you really think through your strategy and technology from a people perspective? I think so.
Let’s take a look at an example of how user personas might help in technology selection.
Imagine you’re tasked with selecting a Web Content Management System (WCM) for your organization. The idea is to allow a large portion of users to have access to the WCM to create their own content and then push that content through an editing / publishing workflow.
Seems simple enough right? You put out an RFP and begin your technology selection process. You look at demos and have tons of meetings and finally select the ‘winner’ based on your selection criteria.
You’ve developed your requirements for the technology. You know what you want the WCM to ‘do’…but do you know what users will be using it and/or how those users will interact with it? Does the new WCM align well with your organizational culture? Is the chosen platform usable and useful to the people in your organization?
Sure…you want a platform that is ‘easy to use’, etc…but ‘easy to use’ for you is different than ‘easy to use’ for Janice, the 65 year old user from Group X who’ll be the one responsible for updating the content for that group. Will Janice be able to use the content editor screen of the WCM to input or edit content ? Will she have to know HTML to do her job?
Does the WCM you’ve chosen allow a user like Janice to do her job without some serious customization? If not, what work will be needed to make it easier for Janice to embrace this new platform?
The answers to these questions are strictly dependent on how you develop your selection criteria….and I think user personas will help. By crafting user personas that covers the broadest range of users, you ensure that the people using the technology are considered. Building a set of user personas for your internal user groups will help you not only craft a good technology strategy but also help in selecting the right technology platform for your organization.
Personas have been used for years in the application development and web design/development fields…but I’ve never seen them used for technology selection projects. I’ve seen some consultants use user stories and user scenarios for technology selection and strategy projects but I haven’t seen personas …..have you?
If you’ve used personas in technology selection projects, I’d love to know how they worked out for you.
I’ve been talking to quite a few folks recently about Sharepoint 2010 to get feedback and insight into the product’s current acceptance and usage rate.
One key area that interests me is around content management and content management systems. I’ve worked with a lot of them in the past and my two favorites right now are WordPress and Sitecore. WordPress is a no-brainer for individuals, small businesses and is a very good platform for medium / large businesses with a bent toward open source software / LAMP.
For those organizations that have a .NET focus, Sitecore has done well for itself over the last few years and is great for those businesses some money to spend for Sitecore licenses and development efforts.
Lately, I’ve been hearing from friends and colleagues that Sharepoint 2010 is being hailed as the next great content management system (and/or collaboration platform and/or search platform and/or …). Of course, those touting that are Microsoft and their sales / partnership channel for the most part. I say that partly in jest, but also because I haven’t found many developers, content specialist or marketing person to echo that statement…none have been impressed with Sharepoint as a pure Content Management System (CMS). Does this mean Sharepoint as a CMS is bad? No…just means that its features haven’t been enjoyed by end-users.
For those of you out there with any history in IT, you’ll know that Sharepoint has been around for quite some time and there have been many iterations and foci of this platform. Its a document management system, a work-flow system, intranet system, security management system and has been used for much more. The new 2010 version is being touted as “collaboration software for the enterprise” by Microsoft….which isn’t a bad marketing approach.
Sharepoint is a great platform for collaboration and community. I’ve seen some wonderful systems built for those functions….but is it a great content management system? Can it really compete with pure CMS platforms like Sitecore?
Sharepoint 2010’s new content management features are impressive, but anyone with experience can see these new features for what they are – a classic Sharepoint reorganization and reuse of functionality plus some new features to bring out this ‘new’ CMS functionality. I don’t mean this in a bad way…this is one of the strengths of Sharepoint…it can do most anything.
Sitecore, on the other hand, is built to be a CMS from the ground up. There’s no pretense that Sitecore is anything more than a CMS. That’s why I like it so much. Is the product perfect? Nope…but no product is.
So…which is better as a CMS….Sitecore or Sharepoint?
For a pure content management system, I’d pick Sitecore hands down. The system is built to be a Content Management System and has a focus on communications & marketing. Sitecore is focused on delivering content to external audiences and improving insight into website visitors and user experience via new products like the Sitecore Online Marketing Suite.
Of course, Sharepoint can be used as a CMS and is now being touted as one, but I currently find it hard to recommend Sharepoint solely on its CMS capabilities alone. Of course, very few IT shops are going to look at Sharepoint for a CMS only…most are already using Sharepoint for other functionality like internal collaboration, document management, security, etc and their focus may soon move to using Sharepoint for external focused content delivery.
I’ve implemented Sitecore and Sharepoint and used both products. I like some things about Sharepoint and some things about Sitecore.
So…how do you choose between the two? I’ll never tell a client or company that one technology or platform is better than another…but I do like to point out differences. Here’s a quick list of things that I would think about when choosing between the two products:
For an external content focus, choose Sitecore.
For a marketing driven platform, choose Sitecore.
For a platform to customize the web user experience based on non-authenticated users, choose Sitecore (and the Sitecore OMS)
For an internal content focus with enterprise level security requirements, choose Sharepoint
For a collaboration platform, choose Sharepoint
For an IT driven platform, choose Sharepoint
Some IT shops will argue Sharepoint should be chosen over Sitecore for some of the above reasons (namely security for content delivery, etc) – butthose arguments can be countered easily with Sitecore’s extensibility and features. I can plug modules in that allow me to use the same security systems that Sharepoint uses. Of course, there are modules that can be plugged into Sharepoint to get different/more functionality as well
At the end of the day, comparing Sitecore and Sharepoint as CMS platforms is like comparing apples and oranges – they are different products targeted at different uses. Sharepoint can (and is) used as a CMS – but Sitecore has a more robust CMS feature set for marketers.
If you are looking for a .NET based CMS, either product will work – but right now, I would lean toward Sitecore when looking for a pure CMS that provides fast development times, stable platform and ease of use for non-technical content creators.
Of course, each organization is different…don’t take my word for it…check out both products and run them through your technology selection process to determine which is best for you.
In the IT world, we tend to take a single-minded approach to our technology platforms. We have email systems. We have web systems. We have HR and Finance systems.
Many organizations are implementing collaboration tools and social tools in the enterprise. But…most organizations are implementing these platforms with blinders on without long-term plans for how those tools might need to adapt for how users really want to use it.
As we’ve seen in recent days/weeks in events around the world….technology is being used for much more than that. Technology is being adapted for their situation. They are using the tools at hand in ways that weren’t really considered when those tools were created.
The truth is that tools take on a life of their own once put in the hands of human beings, who, by nature, are innovative. People are hard-wired to adapt tools in ways the toolmaker never intended — sometimes for the good and sometimes for the bad.
How many times have you seen a technology platform implemented within a company to find that nobody uses it…or….people use it differently than planned? It happens often.
If you are planning a new technology implementiation, are you thinking about how your people will use that technology? Are you thinking about how that technology might be used (or not used) once implemented. Are you thinking about the culture of your organization and how the technology fits with that culture.
You know people will attempt to use a technology differently than originally planned…so are you planning for those changes to come in the future? How will your technology strategy & platforms accommodate these changes.
Something to keep in mind during your next technology assessment / technology selection project…you don’t want to build a square peg today and find that you have a round hole next year, do you?
In my article titled Technology Selection and Cultural Fit, I argue that cultural fit is an important aspect to consider when undertaking Technology Selection projects. While the article was well received by most folks, I did have a few people comment (privately via email and twitter DM) that I was making some broad statements that couldn’t be backed up with hard proof.
I’m all for backing up claims with evidence. I mean I am working on my doctorate you know…nothing like a doctorate program to teach you how to base theories on evidence right? 🙂
So…let’s take a second to revisit my theory that cultural fit is important to technology selection projects. We’ll start by taking a second to review the idea of Technology Acceptance.
To get started, let’s take a second to review a highlight from my previous article:
…failure to consider organizational culture prior to or during a technology selection project can be disastrous…
Now…the rest of this article dives into why I think culture is a key component of technology acceptance.
Technology Acceptance within Organizations
The Technology Acceptance Model (which I linked to in my previous post but didn’t really discuss) was introduced and popularized by Davis and Bagozzi in the late 1980’s and early 1990’s. You can find a brief discussion of the model on Wikipedia or you can dig through the following papers:
All are great papers and provide a good introduction to the Technology Acceptance Model (TAM for short) and how it can be used in organizations.
The model boils down to two major points for consideration during technology selection. A quick discussion of these points follows.
Perceived Usefulness -The understanding / belief by a user that by using a new technology they will be able to do their job better / faster / more effectively.
Perceived Ease of Use – The understanding / belief by a user that a new technology will be easy to learn and use and will require little effort to use on a regular basis.
Notice that the model uses the word “perceived” for both major issues affecting technology acceptance. Perception is key….if the users perceive that something is difficult to use or that it will not make their job easier, they will not use it to its full potential…if they use it at all.
The TAM has been built upon many research projects, all of which are very rigorous and the model has been the basis of a ton of other research projects with similar results.
Based on my research and my experience, I believe the Technology Acceptance Model is a fairly good model to use as a rule-of-thumb while looking at an organization’s ability to accept a new technology. In fact, in most of my technology selection projects, I’ve used the TAM as a starting point when surveying organizations to help determine a baseline for the organizations willingness to accept new technology.
Acceptance is an important aspect to technology selection wouldn’t you agree? Without acceptance, technology is useless.
Technology Selection, Acceptance & Culture
Now that we all have a baseline understanding of one theory around technology acceptance (there are other more complicated theories than the TAM), let’s take a second to look at how culture plays into this and how it can greatly affect technology selection.
I think we can all agree that acceptance of any new technology is important. The perception of the usefulness and ease of use of any new platform is extremely important. Definitely something to consider during technology selection projects, no? I believe these two areas (usefulness and ease of use) are considered during selection projects, but I don’t think the real underlying cultural aspects are well understood. What do I mean by the ‘underlying cultural aspects’ behind ease of use and usefulness?
Organizational culture plays a large role in creating the concept of ease of use and usefulness to an individual. Think about it this way…ease of use and usefulness is a factor of how a person perceives technology as a whole and for the most part, that perception is shaped and driven by the underlying organizational culture. While the TAM is a bit too simplistic to model every individual’s reaction to new technology, it can be used as a baseline heuristic for how well the organization will accept new technology.
The culture of an organization plays a large part in the individual’s reaction to new technology and platforms. Before undertaking a technology selection project, if you can take some time to understand the the cultural proclivity towards acceptance of technology, the selection project might be more successful. With the culture of the organization better understood, you can add some additional filters a more robust selection criteria.
Have I provided “proof” that my idea of culture playing a large part in technology selection project outcomes? Nope…but I might find a way to do so in the future 🙂 Sometimes you need proof…sometimes you can just go with faith that something feels ‘right’ and you should go with it. With this particular issue, I feel that organizational culture has played such a large role in the success and failure of technology selection projects that it feels ‘right’ to say culture and technology selection are intertwined.
Stay tuned for more on this topic…I’m hoping to put together another post with some actionable items for use in your next technology selection project.
Did you know that technology selection is about much more than technology?
Yep…its true…..but most people don’t realize it.
Many in the IT world love to get asked to be a part of a technology selection project. These types of projects usually provide a learning opportunity for everyone on the team and an chance to really help drive the platforms used within the enterprise.
The basic question at hand for most technology selection projects really comes down to “‘what do we need and how much is it?”
With that question in mind, most IT professionals approach technology selection with the following three questions in mind:
These three questions definitely cover a great deal of requirements….but one major area is missing. I’d add the following:
Does the technology fit the culture?
Pretty broad question but one that’s extremely important to answer.
Now…one could argue that cultural fit should fit into the non-functional requirements or selection criteria selection questions…and I’d agree. That said, very few people really consider organizational culture when choosing technology.
Cultural Fit – why worry?
Why should we worry about cultural fit when selecting technology?
Company culture will dictate how much support for a new technology is required. It will make a difference whether your users will take it upon themselves to learn a new technology or expect to have their hands through detailed training classes.
Culture will also determine how technology is used. Will the technology you select and implement by used in some new, innovative way or will it barely be used for its intended purpose?
Cultural fit is just as important to an organization as functional requirements but its an often overlooked step in technology selection.
A Case Study in Cultural Fit and Technology Selection
I was hired by a large organization a few years ago to implement and manage development and customization for Sitecore CMS. The project was an interesting one…the organization hadn’t used a content management system prior to their selection of Sitecore and had been building all websites using HTML and flat-file databases through a two person web team.
The team responsible for the selection and implementation of Sitecore CMS had assumed that the platform could be rolled out and anyone / everyone in the organization would be allowed into the system to input and manage their own content.
Now…with the proper people and culture, this might not have been a bad idea. But the culture of this organization at the time was top-down command and control where everyone had been conditioned to do as they were told. At the time there was even a paper based communication approval process that required at least 5 signatures (sometimes more) before anything was allowed to be published to the web (this process has since changed for the better).
Can you imagine implementing a technology like Sitecore with built in workflow processes, approval processes and publishing capabilities and to not really use those processes because a paper-based approval system existed? I will note that the Sitecore driven workflow processes were considered as a replacement for the paper-based system but never properly embraced or used.
With a culture built around waiting for your boss to tell you what to do, do you think the CMS platform was accepted and embraced by the users?
Another issue that was obvious from the beginning of this project was the complete lack of understanding of everything ‘web’ within this organization. This was very much an organization with a “print” mentality and modern digital communications and marketing concepts weren’t well understood by most.
Needless to say, the plans to roll out Sitecore to the entire organization never really panned out. There were pockets of people and teams within the organization that were chomping at the bit to get into Sitecore but that was the exception rather than the rule.
Technology Selection – Lessons learned
What can we learn from this example? The strategic objective behind selecting and implementing Sitecore was sound. So were the functional requirements…the platform is an excellent platform and fit into the organization’s overall technology architecture and roadmap.
A failure occurred when the technology met the culture of the organization. The culture was rooted in ‘do nothing wrong’ and ‘receive approval for everything’. This culture let the inability for the people within the organization to understand, embrace and use a technology that allowed individual achievement, initiative and innovation.
If the real goal of this organization was to put the power of digital communications and marketing technology in the hands of individuals (with proper workflow processes of course), a first step should have been to take on some form of organizational readiness study prior to technology selection. If this had been done, perhaps a different technology would have been selected or at least a different plan for rolling out the selected technology could have been created. Perhaps some organizational & cultural changes could have been implemented to allow this technology to better serve the needs of the company & people.
Regardless of what could have been done differently, the basic lesson is this: failure to consider organizational culture prior to or during a technology selection project can be disastrous. Next time you take on a selection project, add the ‘cultural fit’ question to your list of things to consider…you may just be surprised at how differently your selection criteria and project turn out with this in mind.