Change: Embrace It or Get Out of the Way Because Change Happens!

Again a several weeks have gone by since I’ve written anything here.  It has been a busy month and half.  The first half of June we were preparing for our move from SharePoint 2007 to SharePoint 2010.  Then around mid-month, we ‘froze’ the portal while we converted all of the sites (a little over 4300) from SharePoint 2007 to SharePoint 2010.  In the process, we also changed the calendar used by all of the schools and had to manually update the branding for each of the 170 schools.  Our team spent a little over a week working long hours for about 10 days in a row to get the new site off the ground.  Even after we were ready, we encountered some additional unexpected problems with the load balancing and SSL for the web servers.  But finally, everything was up, even though there were battle scars.

We encountered some pages that had ‘strange’ formatting.  We eventually narrowed the problem down to pages that had content that was copied from MS Word back in SharePoint 2007 without first removing all of the inline formatting.  SharePoint 2007 apparently was more lenient.  SharePoint 2010 did not like it at all replacing a lot of it with blank spaces and blank lines.  No easy way to fix that except manually update the affected pages.  Another problem was that many pages had web parts that suddenly appeared centered instead of right justified.  Unfortunately, these web parts did not have any properties that controlled the text alignment.  (Web parts affected include a FAQ web part based on the Content Query web part, the Summary Links web part and a few others.)  We found that it was getting the text alignment from the underlying zone formatting which was inadvertently left as centered.  That was an ‘easy’ fix by just redeploying the corrected master pages.

We also had another strange problem with images in the Page Image zone that looked fine while editing the page but would completely disappear when the page was published.  This did not occur on all sites, but only selected site collections.  Again we traced this problem back to a problem in the master pages that could be fixed and redeployed.

But these were all technical problems.  The real challenging problems were the people who resisted change.

Yes, change is a four letter word for many people.  Having to learn something new is a worst fate than going to the dentist to get a root canal without Novocain.  Countless people complained that they could not find the commands they needed.  When we pointed out that the commands were right in front of them in the context sensitive ribbons, they said, ‘Well how were we suppose to know that.’  Of course some of these people were the same ones that complained about going from Office 2003 to Office 2007.  Ok, some of them are still on Office 2003 because they don’t believe in ribbons.

I had a 4 year veteran of SharePoint 2007 complain today that they could not figure out how to publish a page.  They never notice the Publish tab that appeared to the immediate right of the Page tab that when selected displayed options to Submit, Approve, and Reject the publishing of their web pages.  Others seemed to have totally forgotten that you need to check in a document before you can submit it for approval.  They would rather say that the new version just doesn’t work like the old one.  I guess in one way they are right.  It does work different in that it using ribbons rather than buttons across the top of the page.  But really, it has not changed that much that a little thought would not figure out.

Also this time around, we did not create tons of documentation like we did for the rollout of SharePoint 2007.  We implemented SharePoint 2007 a few months after it was released in the summer of 2007.  There was not a lot of documentation out yet at that time so we created a large number of documents to help explain a lot of the features and procedures.  This time, since it has been a year since the release of SharePoint 2010 and since SharePoint has gained so much popularity, we felt that there is enough documentation on the web, plus a good selection of books (including mine), that there is no need to reinvent the wheel so to speak.  Therefore, we just included a lot of links, mostly to Microsoft, that explains a lot of the SharePoint 2010 features.  Of course they now complain that it is too much to read, and well, they just don’t have time to search which link would best answer their question.  They would rather have a class.  We tell them that to cover the features of SharePoint for web publishing as well as collaboration, document handling, form generation, BI, Access services and Excel services would require several weeks at best, perhaps 3 days to a week for each major topic area.  They want it all in a single day.

We do conduct what we call ‘Open Labs’ once a month where anyone can come in and we will help them with any problems with their portal sites.  We also during the week answer questions on a regular basis sent to us by email or called in directly.  The problem is, we are not really a training organization, we a designated as an application development organization.  There is a lot we would like to get to to help solve real problems, but we don’t get enough time to get to these issues.

I don’t really mind helping people who are really trying to learn, but are just stuck.  I really get discouraged by people who don’t want to learn and either want to blame everything they don’t know how to do on the new version but don’t want to take the time to learn it.  I guess this comes from my career experience.  I started programming when BASIC programming meant variable names of 2 characters.  My first Apple computer was a Integer BASIC machine that stored programs on a cassette tape recorder.  I subsequently learned on my own how to program in FORTRAN and COBOL.  I helped build a graphics system in FORTRAN that drew large complex engineering diagrams on a bed plotter.  We built the graphics system as a series of subroutines that each did a different graphics component and each could call other components.  In a way it was early modular programming almost object like before object oriented programming became popular.  I then learned Lotus 1-2-3, Multi-Plan and eventually Excel.  I used dBase starting with dBase II and then moved on to FoxBase, FoxPro, Access, Visual FoxPro, and then every version of SQL Server since 6.5 to the current Denalli release.  I programmed in HTML, ASP, ASP.NET before moving to SharePoint.  Change happens.  You either have to love it and embrace it, or you have to find a different career because change will continue to happen.

I have no idea what will be next although my guess is it will reside in the cloud and will make working with mobile devices even easier.  It may be touch related or voice activated, but I do know that it will not be what we are doing today.  Sometimes change takes you down a dead end street with a product or technology that just does not make it in the marketplace.  (I remember to this day working on a book for a luggable portable computer called the Hyperion that died before the book could be published.)    Companies that don’t adapt to the change slowly fade away and die.  Companies and spearhead change sometimes die too when no one else follows them.  The trick is betting on the right horse, the technology, language, or development platform that will transform the industry and take everyone on the next leap forward.

One last point.  The company that I worked at when we developed those cool graphics routines in FORTRAN to create engineering drawings, charts, floorplans and variety of other graphics told us when we asked to look into the ‘new’ CAD systems being sold that CAD system would cut into their profits because they would not be able to charge as much for all the draftsman’s time to draw everything by hand.  It took over 10 years, but that company has gone bankrupt.  Oh, not because of that one decision, but because of the mindset that change could be avoided.

What are your thoughts about change?