SharePoint Killed the Intranet Star?
There was an interesting Tweet earlier from Richard Harbridge regarding the effect of SharePoint on intranet design. The article pointed out several interesting points regarding the complexity of developing on an intranet optimized platform. But while the platform itself has certainly been optimized to support the scope and scale of intranets (both large and small) the platform itself really needs to be tailored to meet the specific needs of the business.
One of the things that a lot of SharePoint implementations lack is a true understanding of how the front end of the SharePoint intranet/portal is going to interact not only with the various backend systems you’re trying to bring together, but almost more importantly with the business process itself. Sure it’s great to put the latest and greatest technologies in front of your end users, but until you truly understand how the end users are going to be interacting with the environment it’s virtually impossible to develop an effective, usable intranet.
When it comes to SharePoint, this is (in my opinion) where we see the biggest level of change; the shift in methodology in how we think about what we’re developing. We’re not “destroying” intranet design, but rather turning it on its end; looking at it from the point of view of the end users. Five years ago we’d be focused on where all of the data is and how to bring that data together, leveraging the power of technology. Today that power extends far beyond the bounds of simply displaying data, offering an environment rich in collaboration (let’s not just show the user some data, let’s let them interact with it). How does Joe Bag-of-donuts interact with this, how do we trim the waste out of the process he’s following, and how do we streamline the communication and flow of data from the publisher to the end user (let’s not forget the power of lean thinking, especially when you’re trying to justify the cost of your proposed shiny new portal to the bean counters).
In your traditional intranet environment that “publisher” is historically a few defined groups, maybe the communications department for example. In the SharePoint powered intranet world, Joe Bag-of-donuts himself can easily author content (still requiring authorization by the communications group before publishing), or create a rich dashboard to share with his specific team or work center. It’s this fundamental shift of looking at things from this “new” perspective, and actually empowering the end user to make decisions that’s ultimately redefining how you develop for the corporate intranet.
I actually know Joe Bag-of-donuts and sometimes empowering him/her can be a detriment to your system as well. I very much like the fact SharePoint allows, if setup, non-IT folk to create solutions to solve their business processes. On the other hand, how many times are you called in to fix the current solution?
Sorry if this seems like a rant, but I’ve ran into a lot of that lately and would like to spark a conversation as to possible solutions…
Cheers,
Matt
I think one of issues is that empowering the end user is often an afterthought. If planned correctly you can ensure that the appropriate approval channels are in place prior to publishing, or to ensure the validity of the solution the end user is creating. Remember that in this particular instance I’m talking about portal content, and basic dashboards (pick from this list what you’d like to see type stuff). Not to give the end user more credit than is due(they always seem to screw something up), but with the right processes and user interface design there isn’t usually much for the end user to screw up. In many cases non-intuitive UI or poor process is what’s at fault, not the raw empowerment of the user.
Touche! That’s taking in consideration your stakeholders actually know the full capabilities of SharePoint. When I initially discussed an approval process, I was looked at as if I had a green head and martian ears. I’m speaking with small businesses in mind here; some of the options SharePoint allows, can be a sledgehammer for some companies. Getting buy-in for something like an approval process would be as safe a bet as me going to Mars. At the end of the day, it really boils down to refined business processes and getting the short-term integrated with a long term approach.
This of course has nothing to do with Intranet design, so I may have to take this offline with you, unless you feel value to have it here… BTW, thanks for getting the all time longest running MTV music video song stuck in my head
.
Cheers,
Matt
I think it’s a valuable discussion to have here… I think we made a full circle and came back to my original point. You said that this has nothing to do with intranet design, but in reality it has everything to do with intranet design. This is the shift in the method of intranet design I’m talking about. In the past we’ve been focused on the raw data portion of the intranet; SharePoint forces us to look at the bigger picture, including business process integration as a component of intranet design.
There are many options under the hood of SharePoint that can simply be missed by Joe-Blow. Unfortunately, I haven’t been afforded the ability to create a grandiose approval process, so I’m looking at this with a completely different view. However, I think it’s great if you can get buy-in from the stakeholders to do so. Lately, I’ve been getting a deeper feeling about SharePoint and what it means to the enterprise and SMB’s. To me they are a completely different animal and need to be implemented differently accordingly. My background has primarily focused on the latter and because of that, often times the bottom line can’t afford some of the capabilities SharePoint can offer. Most of the time, simplicity is more effective. SharePoint may be killing the Intranet by its simplicity, but OOTB seems to work just fine for all of my users.
This is a good discussion going here about this. I tend to really look at the business process piece, maybe deeper than most due to my lean training. As you point out, there is certainly cases where the budget or schedule doesn’t afford the opportunity to really dive into the process, and OOTB may meet the immediate needs. That said, I would argue that a little investment in leaning your process through the technology can go a long way. It’s that type of modernization that shows the end users what the capability of the platform really is and sparks new and creative ideas.
You need to start in baby steps. Bite off little bits at a time and work up (if you can swing it, get some lean training). SharePoint brings people and data together, and does it efficiently. As a result, there are very few SharePoint projects I’ve worked on that haven’t resulted in documented lean savings. What may do fine today, could be driving cost savings or even a return on the project investment tomorrow; and as you start to demonstrate and document those savings and analysis, you’ll get more support from management for future projects.
Lean is a continuous process, you’re never done improving efficiency, reducing overhead, increasing throughput, etc. And that’s a principle that applies to every business from the 10 person cafe to the largest of enterprise.
TCO (Total Cost of Ownership) is a metric I try to incorporate in all of my projects. It’s absolutely critical for any new system to take into consideration the dollar amount on the bottom line. With that in mind, I feel there’s a disconnect with SharePoint between enterprise and SMB’s. Within an enterprise, it’s much easier for resources to be allocated to determine these metrics (TCO being one). As for the 10 person cafe, sometimes all it takes is a simple demo of storing documents online, and it becomes the wildfire of the company.
Most SMB’s don’t have the existing infrastructure to support such a lean approach. Also, from my experience, the forethought put into systems that affect business logic, is really glossed over. Questions like “How will this affect my company after 5 years?” for example. The option to outsource SharePoint is always there, but now we are back to TCO. What I’ve seen and pretty much why I’m a SharePoint fan, is the technical guy of that company will now spearhead the SharePoint movement.
Since installing SharePoint, my role within the company has definitely changed. I’m am now looked at as if I am a developer. My resume doesn’t say anything about code whatsoever. I’m also a business analyst. I review processes, get teams together, and refine them to makes sense. At the same time, I juggle my existing servers, builds, deployments, backup strategies, day to day operations client-side.
If you were to ask my boss the affects of SharePoint on my company, I guarantee he’d never say my job description would’ve changed as a result of a single piece of software. Neither would I for that matter
. I also really doubt he would’ve said 2 years ago, “Let’s run our company using this platform.” Originally, we were using it simply for it’s File Server crawling capabilities. Maybe that was our baby step! What a fun, wild ride it has caused…
With a lean approach in mind, what suggestions would you have for that guy, that one guy that runs the whole IT department, plus is a business analyst, wanna be developer, add your own job description here? I don’t really think I’m alone, but sometimes the blogs don’t directly reflect the actual trenches I’m in. Any advice amigo?
Hold that thought… I think the follow up to your last comment warrants its own blog post.
Excellent idea. I’m all ears…