1,804 articles and 15,514 comments as of Monday, December 27th, 2010

Wednesday, May 27, 2009

You Can Pry SharePoint Designer From My Cold, Dead Hands

Nearly everything I write about for EndUserSharePoint.com involves SharePoint Designer.  In fact, a substantial amount of this site’s content, maybe even a majority, speaks to end users on how to leverage SharePoint Designer to solve business problems.  And now that SharePoint Designer is free, it’s easy for everyone to get their hands on it. 

A lot of people want to use SharePoint Designer and why not?  As Lori Gowin wrote last week, it’s a very versatile tool.  Many End Users can find success with this tool.  That is, assuming the IT department lets them use it in the first place.  That’s not a safe assumption to make.

IT departments are typically skeptical of SharePoint Designer.  As I wrote almost a year ago here, I think this is partly because IT folks are very technical.  SharePoint Designer is not really targeted at IT folk and as a result, it’s considered a second class tool.  However, in IT’s defense, it does go deeper than that. 

In the hands of an inexperienced user, SharePoint Designer can wreck a SharePoint environment.   That’s a potent combination from the IT department’s point of view: a second class tool in the hands of “end users” (who are far from being classically trained computer nerds) that when used improperly, can literally destroy a SharePoint environment.  It’s no wonder that some organizations just make up a blanket rule: “No SharePoint Designer in the building!”

Of course, organizations that fall back to simplistic rules like that are leaving a lot of potential functionality on the table so to speak, leaving business problems unsolved and inefficient business processes intact. 

What do you do if you’re trapped in this kind of environment?  There’s no easy answer.  Depending on the culture of your organization, there may be no good answer at all.  In the rest of this article, I’m going to suggest an overall strategy that ought to open doors in even the most obstinate IT environment.

How do you accomplish this?  The answer is to devise a plan that addresses and implements these key points:

  • Recognize IT’s concerns
  • Leverage your core, innate strength as an End User
  • Learn the ropes

IT People are Worried People

IT people are worried all the time.
They are worried about their current project.
They are worried about their next project.
They are worried that production is going to go down and they will have to work all weekend to bring it back up.
Lastly, they (the good IT people, anyway) are worried that they are not meeting the needs of the business community.  This is where you can come in.

End Users Are the Business

Everyone in IT recognizes that they work in service to the End Users in the business.  Sometimes, IT forgets this and goes off and builds out a solution under the “If you build it, they will come” philosophy of business problem solving.  That philosophy usually results in poorly received systems because in the end, IT doesn’t really know the business like End Users know the business. 

End Users know business rules, business terms, business processes, business partners … everything about the business.

Magic Potions Do Exist

On one side of the pot, we have the technical experts in the IT department.  The IT folk have all the cooking tools.  On the other side of the pot, with all the ingredients in hand, stand the End Users.  The two need to work together in order to cook up something good for the business. 

The answer, of course, is to convince IT to hand over one of their kitchen utensils, namely, SharePoint Designer.  How specifically can you get them to do that?

The Strategy

As an End User, you know how to solve the most important part of the business problem.  You own all of the domain / business knowledge.  However, the IT department has legitimate concerns about handing over SharePoint Designer.  To solve this problem, you need:

  • To learn a little bit about how IT works
  • A safe place to work
  • An IT department that is willing to work with you

IT departments, especially in large organizations, follow a process that is generically called the “software development life cycle” (SDLC) and goes by the name of “waterfall” or “agile” and uses made up or redefined words like “scrum,” “sprint,” and “envisioning.” 

As an End User, you’re not going to learn your company’s SDLC process. 50% of your own IT department probably doesn’t know its SDLC process at any given point in time.  SDLC processes vary from organization to organization and from time to time, and even project by project.  However, for the kinds of things that a typical End User tries to do with SharePoint Designer, I suggest something like the following:

  • Define requirements.  Put words down on paper, or better yet, in a Wiki, that describe what you are trying to solve. 
  • Explain the solution: Again, in your Wiki or MS word document, describe how you will use SharePoint Designer to create a solution that will meet those requirements.
  • Describe your test plan: Think through every reasonable scenario and write these down in the form of “use cases.”  A use case is simply a statement that says “The user is going to perform [X] action and the system is going to respond with [Y] result.”  Be creative.  Think about what happens when users don’t act the way you expect and create a use case for that.  I wrote about this in some detail here: http://www.endusersharepoint.com/?p=544 .
  • Prototype the solution: In a “safe” environment, build out the solution using SharePoint Designer with as much real data as possible.  Walk through the test cases and make sure they work as you envisioned when you wrote them in the first place.  I use the word “safe” in the sense that IT considers it a safe environment; if you accidentally damage the safe place, it won’t take down the production server or cause other administrative headaches.

This last point is potentially a sticking point, but it shouldn’t be, but you may need to be a little patient.  There are several ways to get your hands on a safe environment:

  • Ask IT to create an environment for you.  IT has several good options, including:
    • A separate site collection in the farm.
    • A separate site in a site collection.
    • A personal virtual machine.
  • Obtain a demonstration virtual machine from Microsoft and install it onto your computer.  These are fully featured environments that you can use on your own with little or no IT support.  Build out your solution and demonstrate it to the right people and it’s bound to be accepted by your organization.  You can look here for one: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=67f93dcb-ada8-4db5-a47b-df17e14b2c74

Conclusion

The objective and desired end result of this strategy is to get the IT department to trust you and your ability to help them meet the needs of the business.  It definitely takes some patience and is really a social engineering exercise.  Along the way, you’ll learn a little bit about how IT operates and if you follow the simple pattern of obtaining requirements, designing the solution and testing properly, you’ll both impress the IT department and build superior answers to your business problems.

Paul Galvin, MVPPaul Galvin, Microsoft MVP – SharePoint
Web site: Paul Galvin’s SharePoint Space

Paul is a Solutions Architect currently working most closely with Microsoft Office SharePoint Server 2007. He was recently awarded Microsoft MVP – SharePoint status for his work with the SharePoint community.

 

Please Join the Discussion

17 Responses to “You Can Pry SharePoint Designer From My Cold, Dead Hands”
  1. Andy Burns says:

    “End Users know business rules, business terms, business processes, business partners … everything about the business”

    Wow, I’d like to meet them. Most users *think* they know these things – but different departments use different terms, business rules turn out to be based on ‘well we know those guys’, and processes often have stages like ‘if the order is over $xxxx and it’s a Tuesday and you’re facing north, we give the file to Bob’.

    That aside, I think that you’re right, both users and developers (’cos not all IT are developers…) do need to meet in the middle, and understand how to talk to each other. I genuinely believe that my job as a developer is largely about understanding users languages. I like idea of teaching users how to state their requirements, and how they would test it; it’s a step towards my language too.

    However, seeing business users try and define the ‘how’ of things is painful. Typically such efforts do descend into trashing a system; usually the user’s focus is too much about what they want to do to the exclusion of everyone else.

    Doing such things as a prototype might be useful. It’s another way of trying to communicate what you’re trying to achieve, and anything that aids that is good.

    And I’d be surprised if as many as 50% knew their SDLC…

  2. Kevin says:

    I believe the term “End User” might need some work and consensus. It seems to mean different things to different groups of people throwing it about.

    The end users in my community have no business using SharePoint Designer, or even trying to implment most of either Pauls tips and trinkets. Heck they can’t even remember their own passwords or how to do basic tasks in Outlook or Excel all too often.

    But who are these IT folks and departments that are often described as wanting to prevent SPD use? So they’re not using it themselves we can surmise.

    So who is using SPD? And what other tools and techniques are these folks using and trying to use?

    I need better terms. I’ll bet many of us do. I don’t want to outlaw SPD use, but I do need it in the hands of someone other than “end users”.

    Kevin
    Director of IS for a construction engineering firm. Former principal of significant MS Gold Certified Partner

  3. Kevin says:

    I should have added I do indeed wish I had a class of user that I could trust SPD like tools to.

    We need better trained users, and better trained IT depts.

  4. Kat says:

    I agree with Kevin about the term “End User.” At my company, our end users have no business getting “design” permissions, let alone use of SPD. The large majority here want and need to remain “contributors.” I refer to our more skilled folks, our designers and admins (the good ones, anyway) as “power users.” I could maybe trust a few of them to get a hold of SPD, but I would worry about most. I use SPD, but I’m very cautious and study and test just about everything. I’m paranoid about blowing things up. :) I’m not in IT, but I am our intranet manager. I’m currently the only one using SPD (that I know of, anyway). I would love it if we had more people properly trained and able to use SPD- right now, the burden is on my shoulders to develop any special workflows or page layouts or other things really only possible in SPD (Visual Studio is not an option- we have no SP developers). It would be nice if others were trained to do this, too. I have some power users who actually Google error messages and read blogs and buy books and have a real thirst for learning SharePoint, but they are a rarity. I want to clone them! :)

  5. Paul Galvin says:

    I appreciate the very thoughtful comments people have left here so far. I clearly should have defined what I mean by and “end user” in this article.

    The social engineering aspect to this is really targeted at those kinds of end users that you would consider a “power user”. If you’re an end user reading content on this site then I think you’re right in line with the audience I have in mind.

    I’ll respond in greater detail as I have time, maybe even with a new article on the subject.

  6. I have an article coming out defining the term “End User”. In short, there are various levels, including Information Worker, Power User/Site Manager, and Site Collection Manager.

    These groups each have specific uses for a site and therefore can be assumed to need different skills sets.

    As many have send, “End User” is an ambiguous term. Let’s see if we can get that cleared up.

  7. Kevin says:

    Collectively we seem to have struck a nerve :-)

    I’d respectfully suggest that the contributors and moderators at EUSP are not themselves “end users”.

    That said, they offer some GREAT solutions for those of us that are yet to be defined. I’m not a developer, nor am I and end user, but I’m making SharePoint do what our end user community needs w/o breaking out heavy duty dev tools or letting out dev contracts for it.

    I look forward to your article. Thanks!

    Kevin

  8. Kat says:

    I look forward to the article, too! Yes, it is tough to define, and yes, every company works a little differently. Where I work, we have the “information worker” end user (if that’s the most entry-level term) who simply reads and contributes in various sites, then we have some more advanced end users who “get it” and can become designers and admins of sites (but they still require a lot of hand-holding and prefer to be taught everything w/out doing their own research/reading). Then we make a big jump to the few end users I love…the ones I truly consider “power users” because they WANT to be doing this and they try things on their own and read and learn…but they still have full time work that keeps them from delving as deep as they may like. Then there’s me- full time on SharePoint, responsible for overseeing the entire intranet and training power users, planning out the architecture, working on larger enterprise-wide projects, etc. I get to dive into SharePoint almost completely. I just don’t have server access because I’m not in IT (nor do I know anything about installs, service packs, IIS…and I know nothing about development).
    Anyway, there you have one scenario. :)

  9. Ben says:

    My whole (www) career has been based on what I can do that the Devs / Admins (and webmasters – remember them!) say we aren’t allowed to do … without them getting upset and totally locking me down.

    It’s a truism that, within IT (and many other places) we prove our expertise by saying “that can’t be done because of XYZ – which of course you do not understand, and by asking you just demonstrate your lack of knowledge”.

    SharePoint Desinger along with the EXCELLENT work done by Mark / the Paul’s / Dessie / Christophe et al on this site are, daily, arrows in my quiver: DataViews [Conditional Formatting, SQL Integration, Web Services etc.], Master Pages, Workflows the lot.

    I’ve had to put together solutions for clients numerous times in the last year where any call on the central IT team would *still* be scheduled for a Business Analyst to become free to evaluate my request. Want to install an excellent and *free* Codeplex feature? Forget about it. Want a Google analytics tracking code on a master page? – 4 months and waiting…

    I agree completely that the term ‘End User’ means different things to different people. In the context of this site, I have always thought of it as a Site Owner at least, possibly a Site Collection Admin i.e. someone that does not have access to the servers, STSADM or Central Admin (but may like to). That be because that is where I am and what I am looking for.

    BUT… a bit of humility here: SPD can be dangerous in the wrong/novice hands – I have set a workflow to send an email whenever an item changes and then update the very same item … end result 2,700+ emails in about 10 minutes; you learn.

    Not sure there is a catch all solution?

    There is a lot for organisations to benefit from having empowered ’super’ users with the appropriate tools. There is also a liability if there is ignorance that this tool exists and can be downloaded (isn’t *free* attractive?) and used.

    Will be following this one closely … but fair to say: I just about trust myself with SPD not sure how far I’d extend that trust.

    Cheers
    Ben

  10. Ben says:

    Sorry. Just introduced ‘Super Users’ – as if there weren’t enough confusing labels…

  11. Kevin says:

    LOL. Yeah that’s kinda the problem.

    I guess my point was that I’d like those SUPER users to recognize that they are, and that there is indeed a difference between them and end users.

    Whatever you are, keep the tips coming for whatever we are!

  12. Ben says:

    Just a thought. SharePoint / MS promotes a security model of ‘least priviledges’ – add where necessary. You baseline permissions then extend as and when beneficial / necessary. Well … maybe.

    This may apply nicely to SPD — but ONLY if the product and it’s impact is fully understood.

    The only “informed” IT SP admin discussions I’ve had about SPD seem to be hung up on the perils of “ghosting” – which is an old SPS2003 term now referred to as “customising” – not such a big deal in the way MOSS2007 / WSS3 works as far as my reading has uncovered.

    Point is folk with the power to veto need to know what it is they are talking about. Hopefully these same people aren’t Visual Studio vs Front Page veterans… or the battle is lost!

  13. Christophe says:

    @Paul and Mark: defining “end user” vs. “power user” is one thing, actually identifying the power users among thousands of users is another.

    Also, you need to factor in that SharePoint Designer is a buggy tool, you can’t just give it to users without the appropriate warnings. Imagine users carefully backing up their site every week using SPD, and realizing when comes the time to do a restore that it just doesn’t work…

  14. Nice article Paul, good idea to let the IT-people work with SPD in a VPC, so the not need to be worry.. No, education is the way here thogether with an opened mind and a working backup :-)

    - Join http://www.sharepointdesigners.net

  15. Melissa says:

    Designer is a very useful compliment for end users even if they just use it to help manage the files on a site because it’s so much easier than via the browser view.

    But the cold dead hands part.. that’s how I feel about FrontPage because for all the help Designer helps with SP site – it totally screws up older regular websites with all it’s forced CSS.

    Another way with MS feels they know what I want better than I do and it’s not their nasty CSS code on every darn page. Can’t even change a darn font size on an html page without suddenly being engulfed in CSS. If there’s a way to turn it off I haven’t found it yet.

Trackbacks

Check out what others are saying about this post...
  1. You Can Pry SharePoint Designer From My Cold, Dead Hands…

    My latest article is up at http://www.EndUserSharePoint.com . I wrote about SharePoint Designer, End Users and…

  2. [...] Now it’s true to say SPD has its critics, and it’s also true that unless handled with care it can be a dangerous tool.  There have been some interesting posts about its role over at End User SharePoint recently, like this one from Lori Gowin and this from Paul Galvin. [...]




Notify me of comments to this article:


Speak and you will be heard.

We check comments hourly.
If you want a pic to show with your comment, go get a gravatar!