Well organized and managed data can reduce the impact of a lawsuit. Open-ended discovery is very, very expensive to support! So, how does one justify my workshop? It only takes one lawsuit, win or lose. But by then it may be too late!
Well organized and managed data can reduce the impact of a lawsuit. Open-ended discovery is very, very expensive to support! So, how does one justify my workshop? It only takes one lawsuit, win or lose. But by then it may be too late!
Posted by mark@vitalskill.com on February 06, 2009 at 11:48 AM in Governance, Lessons Learned, Quick Hits, Testimonials, Training, Workshops, Speaking Engagements | Permalink | Comments (0) | TrackBack (0)
What do I mean by "normal pretty soon?" I tend to be drawn to new technologies that really matter. SharePoint is one, the Amazon Kindle is another, and there are a few more. One of these days I'm going to write a blog on how to recognize technologies that matter, but that is for a different day.
A while back I was an e-Commerce Strategy Consultant. I had the honor of architecting what was, I think, the first online banking mall. Over 20 banking associations pooled their resources to create a common back end-end of banking utilities that could be easily branded for each of their organizations. This was back when XML was more or less science fiction, and so I had a great deal of fun building a bank around it. By the Grace of God I picked the right pony in the technology race and the bank worked very well.
At the time I often spoke on e-Commerce strategy topics to audiences of senior executives. My favorite speech was given in front of a large number of bank presidents. I told them to go home if they couldn't explain why they wanted online banking. If there wasn't a clear business need, then save yourself 20 million dollars (at the time), save your career, and save your sanity and just go home. This was a rather startling approach for them, but it turned out to be good advice. I would guess about 25% of the room did, in fact, go home. On the other hand, the remaining bankers were ready to step up and "git 'er done."
At the time it was very important, when selecting a LOB solution, to make sure that it was "e-commerce capable," or "e-commerce ready," or some other phrase that indicated that the manufacturer had a sincere desire to slap a web page on the application sometime "real soon." I did a lt of speaking then too, and I explained to my audiences that in two years or so e-commerce would be absolutely normal. The day would soon come when the customer wouldn't even have to ask if a tool was "e-commerce capable" because e-commerce would be a natural part of everyone's thinking. Of course this met with a great deal of skepticism.
Now, once again, you are struggling to find applications that are "SharePoint Ready," or to find custom gizmos that will hook up your LOB systems to SharePoint, or to find a consultant who can work a little magic for you.
Remember that you heard this here first! In a couple of years you won't even think about SharePoint. you'll still need tools and training, but it will all be normal. LOB apps will ship with BDC connectors and webpart interfaces. It will all be normal.
SharePoint is the new Windows, or soon will be. When Windows was a baby called 3.X, it was an application interface that installed on top of DOS. Over time DOS's funcitonality was subsumed into Windows. The same is happening now. SharePoint installs on top of Windows, but over time the two will become one virtualized program environment.
Trust me that this is the direction things are heading toward. I am not psychic, it is just that this isn't my first rodeo. I was actually a client/server consultant back in the day. the whole concept of client/server blew people's minds. They didn't know whether to laugh or cry. When was the last time you brought in a client server consultant?
Posted by mark@vitalskill.com on February 05, 2009 at 11:15 AM in Lessons Learned, Organizational Change, SharePoint 2007 | Permalink | Comments (0) | TrackBack (0)
My blog post on evaluating SharePoint consultants was only meant to draw attention to the fact that there is far more to the story than development and administration expertise. So how do you proceed using SharePoint if you don't have an unlimited budget?
1. It is always a good idea to get some help kicking off your project, especially where new technologies are concerned. That is the idea behind my Governance and Taxonomy workshop. It is best when it is completed before you have rolled out SharePoint, but can be used to put SharePoint "back on track." It covers Governance, Taxonomy and a Project Charter. And it is not, by any means, the whole story. That is why I hold it down to two days, to limit your cost. This may seem like a luxury, but it is hard to have a project end well if it doesn't begin well.
2. Next it is a really good idea to get a SharePoint MVP to come in for A DAY OR TWO to help develop and validate your deployment plan, infrastructure,and capacity plan.
3.Invest in SharePoint Administrator Training. Rather than invest in more consulting, at this point it is important to develop your own staff. This is true whether you have a staff of two or two hundred supporting SharePoint. You need to make sure you have the internal expertise to keep SharePoint alive and cared for. This takes about four to five days of training with a live instructor. There is a definite mentoring process that is needed to gel the administrator's thinking and behavior patterns organized, so a live trainer is essential IMHO.
4. Invest in Site Administrator Training. This end user training goes by many different names, but you are going to need to have intelligent and motivated business folk do the majority of the heavy lifting when it comes to creating and maintaining sites.
5. Invest in Developer Training. Although I hammer away at the economics of custom development, it is an excellent tool for your organization, when it is properly used and implemented. Again this is, in my opinion, best done with a live trainer.
5. Do invest in a few books.
6. Go as far as you can with the out-of-the-box toolset, templates and webparts.
7. Join a good User Group. I can't emphasize the importance of this enough!
8. Buy your custom BDC tools, web parts, and master pages off the shelf. Use Bamboo Solutions, Lightening Tools, and other reputable tool manufacturers. Their stuff is usually pretty cheap.
9. Establish a good relationship with a consultant or consulting organization that has strong developer and administrator skills. This is, at the end of the day, where you will need the most help.
10. LOB integration is probably not something to do right away, so don't worry about this one just yet. this is definitely not a Mercury Capsule project. It is more like a Space Shuttle project.
11. Make sure your other technology partners and vendors are bonafide Microsoft SharePoint partners. When it comes to storage planning, you are going to have to rely upon your NAS or SAN vendor and they are going to have to understand SharePoint.
12. Do go to conferences where you can rub elbows with vendors and peers alike.
13. DO NOT fall for every snake oil salesperson you meet in the SharePoint Space. If somebody has a whiz bang tool or application that magically solves all your problems for you, then you are going to want to validate that it actually works. Rule of thumb--if an application or tool takes away the pressure to think through your organizations' management and technology issues, then it is most likely bogus. You are still going to have to do the heavy lifting when it comes to thought and preparation. Again, that is why I created the workshop.
14. MOST IMPORTANTLY - Start small! Remember to build your Mercury Capsule first (a site or site collection), then your Gemini Capsule (a larger site collection or two) and then your Apollo Capsule (your first enterprise deployment).
15. Wait a while before you start building externally-facing solutions with SharePoint. It is much less embarrassing to mess up internally than it is to do so in front of the whole world.
16. Find a graphics, marketing and advertising agency capable of creating and modifying Master Pages.
17. Treat your internal SharePoint people very well indeed. They are part of the most employable technology profession on the planet. If they are any good at all, someone else is going to hire them if they can. So don't overwork them, undertrain them, and under support them. If you ignore them they will go away.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Posted by mark@vitalskill.com on February 05, 2009 at 10:49 AM in Best Practices, Consulting, Lessons Learned, Project Management, Rules of Thumb, SharePoint 2007, Taxonomy | Permalink | Comments (0) | TrackBack (0)
Beats me, but here are some practical thoughts on the topic:
1. If you take a developer with 30 years experience in COBOL programming, and send that person to Java school, they will write COBOL programs in Java. The same holds true for training SharePoint development training. It isn't enough to teach your developer to grind out code according to a certain syntax and programming model. You have to teach people how to think as well.
2. Your newly minted developer will not understand what SharePoint is or how it is used, unless you send them to "power end user" training. It is quite possible to write technically correct, beautifully structured code that completely misses the mark as far as the warp and woof of SharePoint is concerned. SharePoint is all about the end user, and if the developer doesn't take the time to find out what the end user does with SharePoint, then they are going to create bizarre and dysfunctional applications.
3. Developers would rather die, by and large, than go to End User Training.
4. The ideal SharePoint environment needs no development at all. By this I mean that development should be avoided at all possible costs unless you really, absolutely have to have it. Custom code costs tons to develop, tons to maintain, is a source of failure and security breach, and will cost you tons more when you have to uplift to the next inevitable version of SharePoint. The economics are very much against custom code. Custom SharePoint code should be as rare as custom Excel code. You will still need custom code, but it should (IMHO) be your absolute last choice when trying to solve a problem.
5. There are a lot of great companies out there like Bamboo Solutions and LightningTools that make great web parts, BDC tools and the like. Buy off the rack before you develop.
6. Few things are more dangerous than developers with time on their hands, so keep them busy doing something.
7. Let the end user try to find a way to solve a given problem before going to code.
8. There are definite times when custom code is required: The need to aggregate information across unusual boundaries in the system. The desire to create a custom web part that can be deployed everywhere. An example might be a bank that desires to have a web part that calculates mortgage estimates according to the best practices of the organization. That way all employees are on the "same page" when it comes to discussing and selling mortgage scenarios.
9. You aren't going to learn to be a decent developer from an online course, a book, or a series of magazine articles. There is, in my opinion, a mentoring component to learning good development practices. This is one area where I think it is vital to have a live instructor.
10. In the new world, the developers build the Lego's and the end users use the Lego's to build "stuff" in SharePoint. Developers in a SharePoint context will spend most of their time building little bits and pieces rather than grand behemoth software applications. Keep your requierments few, your timeframes short, and your process radical.
11. Customization can take on many forms - Custom workflows are a good idea, custom pages are a good idea as long as you don't violate the ability of the page to support inheritence for features you aren't currently using. Custom data connections are going to be necessary in the long term. Custom web parts will be necessary too. Be careful about custom packages where a site template or definition comes to you heavily customized on multiple levels. SharePoint is intended, IMHO, to offer the end user a series of tools that can be used to build and modify solutions as they arise. SharePoint is not intended, IMHO to provide IT yet another avenue for tightly locked down and non-standard complex solutions. I truly believe that the most cost-effective future is for IT to provide the tools and building blocks, and for the business user to use those tools and building blocks to solve specific tactical problems.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Posted by mark@vitalskill.com on February 04, 2009 at 02:19 AM in Lessons Learned, Rules of Thumb, SharePoint 2007 | Permalink | Comments (0) | TrackBack (0)
Once upon a time, a major manufacturing company hired me to establish a distribution, training and service network throughout Europe. This was heady stuff for a 26-year-old, and I was having the challenge (and time) of my life. My seven-nation tour ended in the United Kingdom, and I wound up staying at a small suburban hotel near Swindon. Prior to that trip I had no experience with foreign hotels, and so it never occurred to me that the rules were different. I arrived at this little hotel at about 11PM local time. I had just flown in from Stockholm and I was starving, so I called the desk to order late room service. The clerk hesitated a moment and asked if I could "do with sandwiches and milk." I was a little unhappy that the hotel didn't offer the kind of robust room service menu I'd become accustomed to, but I agreed to sandwiches.
I became very irritated when the wait for my sandwiches stretched out to 45 minutes and longer. When the knock finally came to my door, I opened it to find the clerk huffing and puffing. His little uniform was drenched in sweat, and with shaky hands he held out my plate of sandwiches, a cookie and a glass of milk.
Please pay attention to this part--the hotel did not have room service and so he had ridden his bicycle to his own home, made the sandwiches and cookie from his own kitchen, and poured a glass of milk from his own milk bottle. He had then ever-so-carefully ridden my meal back to the hotel. He felt sorry for me since I was young and hungry and far from home. I remain in awe of this good man and try to emulate him often. He humbled me and showed me the path to a better form of customer service--customer service from the heart.
A decade later I was traveling through Iowa in support of a high-tech customer in a tiny low-tech town. I wound up staying at one of those little motor hotels on the edge of town, you know the kind- a flickering neon sign and a serial killer in every shower. At least that is how Hollywood portrays them. When I checked in an elderly woman came to the desk wearing an old robe, her hair up in those little pink plastic curlers, and pink fuzzy slippers. She had cat's eye glasses on and a cigarette hanging from the corner of her mouth. She looked for all the world like a character out of "The Far Side" cartoons. Without thinking I asked her if there was newspaper delivery and coffee in the room in the morning, and she just stared at me blankly, as I signed the registration papers and took my key.
I requested a wake up call as I turned in for the night. Imagine my surprise the next morning when she showed up, dressed the same as before, and handed me a newspaper, a carafe of coffee that presumably came from her own coffee maker, and one of those grocery store sweet roll packages with flat frosted rolls in a tinfoil tray surrounded by plastic wrap. Needless to say I don't think that was standard operating procedure for her. I was in awe of her. That was the fondest wake up call of my entire life. She met my needs, regardless of the inconvenience to herself.
I now have another anecdote to share with you. If you've been reading you know that I'm staying at the Hilton Torrey Pines in La Jolla-- a famous hotel with a great reputation. Last night my youngest son became violently sick. The result was a seriously dirty room, beds that needed to be remade, and towels used in containing the mess.
In the morning the General Manager visited me personally to express his concern for the welfare of my son. The Director of House Keeping personally explained that her staff had cleaned the room and used an ozone machine to remove any remaining odors. She had also arranged to have broth, crackers, water and sprite delivered to my son while I was speaking at the conference. This was world class service. To say that this is a great hotel is one thing, but more importantly it is staffed by great people who have treated my son and me like family. I highly recommend this hotel.
By the way, I'd be remiss if I didn't add one more benchmark of service. When I was in high school, our washing machine stopped working and Mom, being a single parent, was spread too thin to fix it. A friend of the family, Erik Allen (Big Erik) stopped by one night to fix the cord on our washing machine so that it would work again. Here is the stunning piece of information to consider. He was in the final stages of terminal cancer and he was on his way to the hospital to die. As his life ebbed rapidly from him he had the person driving the car take a detour on the way to the hospital so that he could commit one last act of kindness. He had become a follower of Jesus Christ a short time before, and say what you will about Christians, he was seriously dedicated to living (and dying) like Jesus Christ. I have no words to express how much this particular anecdote means to me. It was my 'Saving Private Ryan' moment.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Posted by mark@vitalskill.com on February 03, 2009 at 08:13 PM in Lessons Learned, Life, Testimonials, Travel | Permalink | Comments (0) | TrackBack (0)
Now don't get me wrong, I hate viruses with a passion. Even though I was, and remain, fascinated with cyberlife I hate unauthorized viral intrusions.
Having been around in the good old days before the Internet was privatized, I miss the open and free environment that once represented cyberspace. It was like living back in the 1950s (so I'm told) when people didn't usually bother to lock their doors. In the original Internet (if there was such a thing), nobody locked their electronic doors either.
The law enforcement profiles for virus-writers reads very much like the profile for a Uni-bomber wannabe. Disaffected, polite, keeps to self, shy, alienated, underachiever, higher IQ. So the virus phenomena is definitely dysfunctional. Like you, I have lost data and many weekend hours trying to recover from these malicious attacks.
On the other hand, I think there is an evolutionary purpose for the virus phenomena in cyberspace just like there is a purpose for biological viruses in realspace.
Before viral attacks (and I include all malware) became common, the Internet was homogeneous. Homogeneous systems are prone to catastrophic failure. By defending against viral attacks, the Internet is structured with defensive barriers much like the sealed compartments in a submarine. In an open environment like the early Internet, a single threat could destroy the integrity of the whole system. With compartmentalization, it is unlikely that a single attack (whether natural or man-made) would bring a significant portion of cyberspace to its knees.
I am a big proponent of standardization, but with standardization comes homogeneity and with homogeneity comes systemic vulnerability. So standardization is very important, but so is variance across populations, even in cyberspace.
Back in the days of pandemic plague in the Middle Ages, everyone who was susceptible to a particular disease vector died. This meant that the remaining population was very resistant to those threats. The problem was that those plagues were attacking homogenic populations and so they managed to kill huge numbers of people very quickly. The intemixing of people groups, increased travel and communication (and its accompanying exposure to a wider variety of disease vectors), and repeated pandemics actually produced (in my humble opinion) a genetic stock that was capable of ushering in social systems that covered large geographic areas.
So it is with software attacks and malware. Had a modern software virus attack been let loose in the Internet of the early 1990s, it could have conceivably had the effect of an electronic pandemic.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Posted by mark@vitalskill.com on January 28, 2009 at 11:46 AM in Lessons Learned, Life, Organizational Change | Permalink | Comments (0) | TrackBack (0)
Ages ago I was writing realtime process control software on a Tektronix 8540/8560 PDP-11 development system. At the time I was pretty high on FORTH, which was a language originally developed to control astronomical radio telescopes. FORTH had almost no overhead and functioned more like a meta-language than a language, i.e. you used it to shape and define your own language environment. It was a language equivalent in concept to UNIX.
FORTH gave me amazing control of the guts and gizmos in the PDP-11 hardware. I realized at one point that, after I was through commandeering the system, I could have my software keep part of it indefinitely. I could then write self-replicating software that would "live" in the system resources I kept. This was before I'd even heard of viruses, and I became obsessed with synthetic life. FORTH was the ideal language for this and so I played. It was a lot quieter than my prior efforts at generating music using Markov equations and fractals, so my then-wife considered it a move in the right direction.
Recently I asked myself a fundamental question-- "what is the most successful software concept in history?" I think it would be safe to say that the most successful (in a Darwinian sense) software concept is the software virus, which first caught my interest so many years ago. These simple little critters can be written and deployed almost anywhere. They manage to survive numerous attacks to eradicate them when traditional technologies take great effort to keep operational. They reproduce and move. They are a royal pain in the nether regions.
So, it seems that future software might eventually become more virus-like. Since the cloud is closer to viral than is a traditional deployment, I'm thinking that a viral concept may well be the next stage in software infrastructure evolution.
There is currently a bit of a debate on whether cloud architectures will endure. Since they are the most virus-like, I think they stand a very good chance.
©Copyright Mark Ragar Schneider, 2009 All Rights Reserved
Posted by mark@vitalskill.com on January 28, 2009 at 11:29 AM in Lessons Learned, Life, Organizational Change, Taxonomy, Web/Tech | Permalink | Comments (0) | TrackBack (0)
Friends of mine were medical missionaries in Cameroon for many years. The local folk had legends about demons that would occasionally arise out of a local lake and steal the souls of the local villagers. Westerners in general tried to educate the locals that there are no such things as demons, and that there was nothing to fear from the lake.
Then on August 21st, 1986 all the livestock and people around Lake Nyos were found mysteriously dead. There was no sign of violence or disease, they had simply dropped dead. Sounds like an episode of X-Files, doesn't it?
It turns out that the lake was actually an ancient caldera and that it periodically out gassed huge amounts of carbon dioxide. The 1986 out gassing traveled at 100 KM/Hour and suffocated everyone in the area. There may not have been demons in the lake, but those legends had helped keep local folks vigilant and safe for centuries. As bizarre as their legends were, the locals needed them. Many cultural legends persist because they are adaptive in some hidden way.
The same may be true in your own organization. Is there an organizational legend or superstition that really annoys you? Be very careful about changing or eliminating it until you understand what the adaptive benefits are. The story may be all wrong but the results may be critical.
© 2008, Mark Ragar Schneider, All Rights Reserved
Posted by mark@vitalskill.com on October 14, 2008 at 09:46 AM in Governance, Lessons Learned, Life, Organizational Change | Permalink | Comments (0) | TrackBack (0)
Information Technology fulfills corporate policies and objectives, period. If the policies given to IT are incomplete and poorly communicated, then IT is not going to be successful. So, in my opinion a high-integrity information management system relies on the following:
Remember that most "failed" SharePoint implementations were technically successful but a failure from a business perspective. SharePoint is a great tool but it is not going to write your business policies for you.
© 2008, Mark Ragar Schneider, All Rights Reserved
Posted by mark@vitalskill.com on October 08, 2008 at 05:07 PM in Governance, Lessons Learned, Life, Organizational Change, Taxonomy | Permalink | Comments (2) | TrackBack (0)
According to a recent article in Information Week
Even employing precise keyword searches,Verizon (NYSE: VZ) places the price of processing, reviewing, culling, and producing 1 GB of data at between $5,000 and $7,000, according to a study by the University of Denver's Institute for the Advancement of the American Legal System. (Click here for full article)
This means that a simple search appliance will, in the long run, be a very expensive solution to an organization's search requirements. Search appliances are good but they can't do your thinking for you!
© 2008, Mark Ragar Schneider, All Rights Reserved
Posted by mark@vitalskill.com on October 07, 2008 at 08:44 AM in Business, Governance, Lessons Learned, Organizational Change, Project Management, SharePoint 2007, Taxonomy | Permalink | Comments (0) | TrackBack (0)