Archive for the ‘Planning’ category

SharePoint Tips from Indiana Jones?

December 23, 2009

I just commented on Michael Gannotti’s latest post “The Adventure Begins… Productivity Adventures” about how Indiana Jones had a lot of good business lessons. I decided I could probably expand that into a short blog post in case someone out there finds this stuff interesting.

So what sort of lessons, or tips can Indiana Jones teach us that are related to achieving a successful SharePoint?

  1. You have to have the courage to take on something challenging.
    Indiana Jones never ran away from a Challenge (well not the ones that mattered). It’s important to first be ready and dedicated to accomplishing a goal. SharePoint is a very challenging thing to implement successfully, and the business problems it helps solve are even more daunting. Courage always helps.
  2. Know your limits and what your good at.
    Remember that scene when Indiana Jones is being chased by that giant unstoppable boulder? While courage is important you still need to know your limits and when it makes sense to ‘run away’. Or in a business sense cut your losses. Sometimes things are unstoppable and we have to be ready to admit it to ourselves to help us survive (hopefully with lots of lessons learned so we don’t do it again). Not every idea you come up with is going to work. SharePoint certainly has limits of it’s own and you also need to understand these.
  3. Simplicity is often the best option. (Gun vs Sword)
    There is a scene, Gun vs Sword, where a scary bad guy is waving his sword around and there is a build up where you expect a big fight. Instead Indy pulls out his gun and just shoots the guy. ( Sometimes the solution to something is simple and there is no need to make it more complicated. This is especially important for SharePoint as complexity often leads to bad choices being made, especially when it’s unnecessary.
  4. You need to know your stuff and be ready to learn.
    Indy is a super subject matter expert and professor in his field with plenty of knowledge about history, archeology and foreign lands. If you are diving into something like SharePoint you should hit the books first, and will need to learn a ton. Not only about the technical aspects but also about the business, and business processes you will be effecting by your SharePoint implementation.
  5. You don’t have to be a superhero.
    Indiana Jones was more or less an ordinary guy who did extraordinary things. We can all be just as extraordinary as Indy. Anyone can implement SharePoint successfully. I mean that.
  6. Some things never change.
    Indy uses pretty old fashioned methods, and techniques often and they work. There is no need to reinvent the wheel if something works. Think about even the traps he faces, most of these are extremely ancient, but still serve their purpose (albeit they aren’t up to the daunting task of taking out Indy). In SharePoint the challenges we face aren’t new. They aren’t unique either.
  7. Know what your are afraid of, or bad at and let other people help.
    Indy was afraid of snakes. He knew it, and we all knew it (because he shared that openly). As a result it is much easier to work around the fears.
  8. You can’t do it alone.
    He also wasn’t the best at everything, and without the help of other people could never have achieved all that he did. Implementing SharePoint successfully is absolutely a team effort and involves many people working hard and effectively together.
  9. You have to believe in yourself and it doesn’t hurt to be unique or have your own image.
    Indiana Jones has a very unique outfit and look. When you see it, it tells you a lot about him and his style, personality and attitude. Your own portal should also have a brand, it’s own attitude even. You also have to believe in it, and get other people to as well. If you don’t think SharePoint is a good  thing, then why should anyone else?
  10. You have to see things through and stay focused.
    Indiana Jones always stayed focused on the treasure or end goal. Constantly moving towards it regardless of significant obstacles. It’s a long difficult journey or adventure to that treasure of an effective SharePoint implementation, but when you get there it is absolutely worth it.

This was fun and I hope you enjoyed it or got something out of it,
Richard Harbridge

Indiana Jones teaches us a lot about important business things. As an example I will go through a couple here.

1. You have to have the courage to take on something challenging. Indiana Jones never ran away from a Challenge (well not the ones that mattered). It’s important to first be ready and dedicated to accomplishing a goal.

2. You need to know your stuff and be ready to learn. He is a super subject matter expert and professor in his field with plenty of knowledge about history, archeology and foreign lands. If you are diving into something like SharePoint you should hit the books first, and will need to learn a ton.

3. You don’t have to be a superhero. Indiana Jones was more or less an ordinary guy who did extraordinary things. We can all be just as extraordinary as Indy.

4. Know what your are afraid of, and work around it. Indy was afraid of snakes. He knew it, and we all knew it (because he shared that openly). As a result it is much easier to work around the fears.

5. You have to believe in yourself and it doesn’t hurt to be unique or have your own image. Indiana Jones has a very unique outfit and look. When you see it, it tells you a lot about him and his style, personality and attitude.

6. You have to see things through and stay focused. Indiana Jones always stayed focused on the treasure or end goal. Constantly moving towards it regardless of significant obstacles.

So I think the photo-shopped picture is perfect Mike! Looking forward to seeing more from your adventures soon,
Richard Harbridge

The Importance of ‘Tuning’ for a More Successful SharePoint

June 2, 2009

One of those things that I have seen from time to time is organizations who have implemented SharePoint not examining the usage statistics, feedback, surveys, or measuring user adoption correctly or on a continual basis. This is extremely important because it allows us to adjust, shift, and improve our SharePoint deployment over time.

From the very beginning of a SharePoint project (or any project) you should determine how you can measure it’s success. The typical two things that we measure on any project is time and money. In SharePoint projects this is still an accurate metric, however it’s important to note that SharePoint is a solution set that delivers value over time. It does not realize it’s full value until some time after the initial implementation has been completed. This is in part due to the considerable training, user adoption, and basically learning  to leverage the functionality best.

So if SharePoint realizes it’s value over time, it also makes sense that if we can continue to improve, focus, and adjust our SharePoint implementation over time it’s considerable value can be further enhanced and even tailored to specific needs. Needs that we will begin to see as the SharePoint platform matures within the organization.

I have never met someone who doesn’t think of SharePoint and almost automatically begin thinking of point solutions, or quick wins.  Personally I believe this is one of the main reasons it’s so hard to think of a larger measurement and long term success of a SharePoint implementation. We are tempted to only consider the individual business cases as measurable and spend our time examining and reviewing these.

It’s also important to examine the entire SharePoint deployment or implementation. This can provide extremely important insight on where perhaps things are falling short, such as training, user adoption in certain areas of the business, or new needs/missed needs of the users. The best part? SharePoint offers a bunch of tools to help and assist in achieving a much better idea of overall SharePoint adoption, and success in areas of the business.

Use Surveys!

The platform gives you surveys which are a great tool that can be used for very flexable and specific analysis requirements. I highly recommend that ANY SharePoint project, and certainly the entire SharePoint ‘comfort’ level of the organization be surveyed from time to time. This can help us get more information than the basic “time and money” metrics. This can tell us how happy people are, how satisfied they are, frustrated they are, or how much they are using SharePoint.

If you haven’t used SharePoint survey’s before. Start now and get a more comprehensive picture of your users, adoption, and “SharePoint Success”.

  1. Plan and Create a Survey:
  2. Responding to a Survey (for the end users):
  3. View and Analyze Survey Results:

Promote Feedback!

Another great thing SharePoint provides is an easy way to organize what I call “feedback funnels”. We can use something as simple as a ‘contact, or provide feedback’ link on each site or area so that users can communicate with the owners and leaders of that content. You could use SharePoint lists for feedback (survey’s as suggested as well) or even InfoPath forms. You could also add in the ability for users to rate content which is another form of providing feedback which benefits everyone.

The important thing isn’t really the ‘how’ this is done though. It’s the building of a culture and people so that they WANT to communicate feedback. It’s really important to help everyone feel like their input is invaluable and important.

SharePoint at it’s base is a collaborative platform. If the organization doesn’t communicate adding SharePoint won’t do anything except perhaps promote visibility of the communication issues, or provide a tool/framework to begin communicating more with and to start the conversations around communication needs in the organization.

If the organization is already collaborative then really drive the point that they are building the SharePoint intranet (as an example) and that with their feedback it can be much better.

Analyze Usage Statistics!

An intranet and/or extranet is similar to a website when it comes to measuring user interaction. Page hits as an example is an extremely important unit of measurement that can help determine what pages may need to be updated, improved, or easier to get to. It’s important to measure the usage statistics regularly and to make them a part of the continual improvement process for SharePoint. There are even webparts you can add or develop that will show the most popular pages, articles, or content for users.

One thing I personally enjoy is the users statistics. When you can see who has, and hasn’t been visiting certain areas of content it can greatly improve your ability to identify people who may need more training, knowledge, support, or understanding of why that area is important and beneficial. It also helps you identify the power users for some of your content. These people are extremely important in improving overall user adoption in the organization and can help take your SharePoint implementation to the next level.

The last example of usage statistics I will provide will be on how search queries and search terms can help you improve search, the taxonomy of your sites, and present certain material on dashboards or homepages. You can even create your own custom tracking, or implement solutions that provide greater visibility of key statistics and indicators. As an example if you have media content the podcasting kit can help show the number of downloads or views of certain material.

That was a fair bit of rambling but hopefully something in here helps someone out there or helps spark an idea that hadn’t been considered,
Richard Harbridge

Updating Content Editor Content with Word

May 19, 2009

There are a number of reasons why users might be using content editors for page content in a SharePoint site. However this creates a fair amount of overhead when users can’t get the content to ‘look just right’. Often without HTML edit abilities users become frustrated and will give up or push content out that has been akwardly formatted.

One of the ways you might try out to help with these kinds of issues is getting users to modify and update content editor content in word. I am going to go through how this can be done (relatively easily) in a few steps here. The important steps in the process is creating an HTML document (in this case I am using word, but you could use SharePoint Designer, or any product which pushes out HTML) and then getting the content editor webpart to reference the HTML document.

  1. First let’s create our web page content in word. It’s important to keep the size of the webpart in mind when we build the content and users MUST insert images as links (from the SharePoint site or internet) as embedded images won’t display. Here is an article on this: *Note we are doing a process similar to smart client authoring/conversion. We are just doing it more manual for greater control/flexability.
  2. Save the word document as the HTML/HTM file type. You can do this simply by choosing SAVE AS and saving it under the HTML file type.
  3. Next we need to upload our HTML (or HTM) file to a SharePoint library.
  4. Navigate to the page you want the content to be displayed on and add a new content editor webpart.
  5. Now let’s edit the newly added content editor webpart’s properties. Namely the Content Link property and set that to reference the HTML or HTM file we just added. To do this you can right click the link in the document library and click copy shortcut and then paste the shortcut into the content link field.
  6. Click OK and save the edited properties.
  7. Voila we should now see the content (built in word) showing on our webpage through the content editor. If we want to modify the content we just need to open the document in word, make our changes and save it to the server. Immediately updating the content on the webpart.

There are two advantages to using a process like this:

  1. You get content version history and version control. Normal webparts don’t really have version control, so by using a document libraries content like this we can enable versioning and go back to previous versions in case something mucks up.
  2. Any user with access to the content can change it just like a word document (more or less) making it require far less training and effort for people to update than the typical SharePoint methods that can cause alot of confusion.

Hope this helps someone who wants to use document conversion for SharePoint but needs a more flexable model for page content,
Richard Harbridge

SharePoint Not Always “The Answer”

April 15, 2009

Dun dun dunnnn.

As the post title suggests I want to talk briefly about a mentality that I am starting to see pop up everywhere and I want to hopefully illustrate that while SharePoint is totally “sexy awesome” it is not always the best choice for solving an issue.

Anyone who has worked with SharePoint or any technology for that matter for a long enough time understands that it is easy to get into the mentality of ‘thinking SharePoint’. That is the mentality that we immediately take many proposed projects, requirements and solutions and begin mapping them to SharePoint. For those who have done BVPS, or understand the Microsoft Stack they will begin ‘thinking Microsoft’. In my whole hearted opinion ‘thinking Microsoft’ is okay any day of the week. (If you have linux, apple, or other non Microsoft talent/infrastructure then thinking with those technology options also makes sense. For the purposes of this article I am going to assume you are pro Microsoft or have significant investment/talent in Microsoft technology. If not feel free to provide me information in the comments as I am open to alternative suggestions and products.)

What I don’t think is okay is when you start thinking too limited in that giant scope that is Microsoft’s technology offering and begin thinking only in one subset of that technology. In this case SharePoint.

Some examples of other powerful technology offerings from Microsoft are:

  1. Microsoft Dynamics AX
  2. Microsoft Dynamics CRM
  3. Microsoft Dynamics GP
  4. Microsoft Dynamics NAV
  5. Microsoft Dynamics SL
  6. BizTalk Server
  7. Commerce Server
  8. Communications Server
  9. Exchange Server
  10. Identity Lifecycle Manager (ILM)
  11. Forms Server (if using WSS)
  12. Project Server
  13. Groove Server
  14. System Center (Configuration Manager, Operations Manager, Mobile Device Manager, Essentials)
  15. Internet Security and Acceleration Server (ISA)
  16. MapPoint
  17. Microsoft Office (Excel, PowerPoint, Access, Project, Word, Publisher, Outlook, InfoPath, OneNote, Groove, Communicator, Visio)
  18. Performance Point Services (just in case you haven’t looked into PerformancePoint Server)
  19. Search Server (if using WSS)

Couldn’t think of any others off the top of my head here, but you get the point. There is alot out there and you should at least be aware of what each of these ‘do’ or what typical issues they ‘solve’ by reading about them. Almost every one of these can be used with SharePoint and many have integrated webparts and other components which add tons of value to your SharePoint deployment.

If somehow I still haven’t convinced you to check out the other products out there I am going to try and give an example of what I mean when I say ‘thinking SharePoint’ instead of ‘thinking Microsoft’.

New set of requirements pop up, and a solution is conceptualized at a very very high level and someone says “Let’s put it in SharePoint”. You of course being a SharePoint Technologist (Dev, Admin, BA, User etc) say to yourself, yes we can do this in SharePoint and begin breaking down the requirements and mapping a potential solution. (Obviously more analysis, communication etc necessary but this oversimplification gets the concept across.)

Now imagine that high level solution sounds like it relates heavily to the Sales Process and deals with concepts identified and resolved by Microsoft Dynamics CRM. If this is the case then before you go into SharePoint mode you should go into comparison/evaluation mode. Where you take what you know (and most likely clarify/identify more) and evaluate what makes the most sense. In this case building the solution in SharePoint, or implementing the solution using another Microsoft product/service.

In many cases the above example will still be done in SharePoint based on requirements and known information. (Some examples of why it might make sense to use SharePoint always exist such as maybe it’s not a long term solution but a quick fix, maybe it doesn’t need the complexity CRM brings to the table, perhaps you have no talent/infrastructure in house available to support CRM and after evaluating the cost it just doesn’t make sense based on the expected return/value etc etc.)

The important thing is that we were aware that the other technology option existed, we evaluated it, and we also probably will plan for it in some capacity when architecting the solution. SharePoint “can” do anything you want and solve any problem you come up with, but sometimes another technology exists which solves the problems in a more comprehensive, scalable, and cost effective way.

I am hoping at this point you will take a bit of time if you haven’t and read over (from a high level) what the other Microsoft products are. Everyone knows about Microsoft Office (Excel, PowerPoint, Word, etc) but many people don’t fully understand the other Microsoft products which work well with SharePoint. Find out more about them all here: (index is a good place to start) or do a google search and read up about them. You might be surprised by the other existing technologies and how robust they can be.

Hope this helps,
Richard Harbridge

SharePoint 2007/WSS SP2 for April 28th

April 15, 2009

Don’t worry I won’t go into all the details. The original announcement is located here: all the interesting details can be found in the above post as well.

Suffice to say lots of important updates (which we all love). Don’t forget that many of the fixes for known issues can be found in the latest cumulative update for SharePoint Server. (Pretty sure February was the last one, and Microsoft shut down December’s due to lots of issues after installation. (Feb from what I hear has no issues))

For those of you who remember end of April was the next scheduled cumulative update, but I am fairly confident this will just be rolled into the service pack.

Personal Items of Note:

  1. In SP2 – Nice little STSADM command to help determine prep status for SharePoint 2010. If you haven’t already begun planning for this consider it carefully now. Think of the talks about 64 bit support and other items of interest and evaluate your current environment. In most organizations I have worked with it takes months to get new hardware and upgrade projects underway so why not try and start some wheels rolling now?
  2. Microsoft will release more information closer to the release date on exactly what issues are resolved in this Service Pack but the last cumulative update and the high level items they outline here are a good indication of what you can expect.
  3. When it does release please for the love of god backup and then test it on development environments, QA environments and eventually on production. Don’t jump right to production. This ensures A) you don’t begin dealing with unexpected issues in ‘panic mode’, B) provides some time for any potential issues to be documented by the community and Microsoft, C) if there is an issue you can back out of it and plan/identify what happened and how to best deal with it.

Looking forward to some wonderful fixes,
Richard Harbridge

Development Specializations, Enhancements, and Experience

March 30, 2009

I found this interesting and can see many different benefits and advantages to using visual organization techniques and spatial representation for development activities.

Code Canvas:

This is a very important concept and I really hope it goes much further than this in the coming years.

We need more creative ideas like this to take place. The concept of being able to see visually represented relationships in code is so key when dealing with how large our development platforms, languages, and services have become.

The entire development experience is still rapidly changing. At the heart of it is our growth and change as a society. Businesses are becoming smaller and more specialized. This allows the business to be extremely focused and deliver more than a larger more broad based competitor (in that particular specialization). More and more we see trends of people becoming experts and specialists in specific niches, and this also maps out to how development is evolving.

For each small style or section of development we create specializations. We have so many different development languages; all with their own patterns and skill sets. Yet at the same time the reason many people choose a development language is a direct result of the tool set, services, community, and overall development experience of that language.

Consider all the different technologies we interact with regularly. Now imagine how many ways those technologies can be broken down. How complex each of those technologies actually is and how hard it is to wrap your head around the layers and relationships each element of that technology might possess.

If we take SharePoint as an example we have front end developers who might be further specialized as experts in master page design, developing themes, page layouts etc. This can be broken down further. Think of what a master page, or page layout could contain. They could be specialists in JavaScript, XSL, HTML, or CSS. We could break that down further and say JavaScript specialists could be further specialized in AJAX or JQuery etc. (Yes I see resume’s all the time with “AJAX expert”, or “JQuery dev experience”)

Think about how complicated the development experience, processes and specializations can be on the front end. There is a lot more there than many people realize. And even as developers we sometimes forget how many skill sets we actually learned in order to develop that SharePoint brand so effectively.

Then the back end get’s even more specialized. Think of all the different pieces of the SharePoint pie. We have workflow specialists who understand the many nuances of workflow development.  We have search specialists who need to understand how language is interpreted and how the most relevant content can be found. Think of how web content or web publishing experts like Andrew Connell understand the many nuances of web publishing. Then there’s the entire BI layer which might go beyond KPI’s, Excel Services, and the such right into SQL Reporting Services, or Performance Point Services. Or how about the BDC or integration specializations?

Now think about that for another second, and you realize that there is normally an IT Administration or IT Pro side to each of these for configuration, implementation and management, as well as a development side.

Now think of one of those pie pieces I mentioned like workflow development and think of how we normally have people who build forms, and business logic, another group who might do data access layer work, another group who might build utilities for both groups etc etc. It’s extremely complicated and the deeper you get the more and more you realize how much is really there under the surface.

Now imagine how all of this impacts communication, how it impacts learning, or staying up to date or fully understanding a product or particular technology.

As a direct result of all of this specialization the entire field of development and technology is rapidly evolving in how we train, learn, and interact. More certifications come out every day, new programs and courses from education groups. More training companies pop up. At the same time we have a wealth of new development tools. Teams and companies that just build better tools to make the development, or learning experience easier.

Tools to build the communities around these groups or help them communicate are generated and tested every day. Or tools to help us achieve a better understanding of the different things we develop, build, or utilize.

We need to continue to grow, innovate and build our development support framework otherwise it will become exceedingly difficult to keep up with the complexities of our technology, and the demands of our users.

This project from Microsoft Research is a great step to helping us better understand just how large and complex our code, services, and development experience has become.

Hope this helps,
Richard Harbridge

SharePoint Ads

March 25, 2009

Many people have probably already heard this via Joel’s blog or the twitter community but I just wanted to reiterate it here.

A wonderful new site/initiative to help SharePoint specific organizations and bloggers/communities to gain mutual benefit from one another through advertising.

There are two things I want to talk about on this – Why is this so awesome? What does this mean?

The first is the obvious growth of the SharePoint community over the past few years. I cannot count the number of SharePoint blogs anymore because new ones chalked full of content are going up every week. People are excited, and as a result are blogging more and more about SharePoint.

This is great news from a product support base, because it means clever ideas and workarounds are going to be more readily available and it also gives Microsoft and the ISV/Partner community tons of potential feedback for their products or customer needs.

Upon the release of I was extremely excited because it filled such a very large need. The site has turned into a wonderfully easy way of navigating the sea of SharePoint solutions and components that are out there. This benefited the businesses around SharePoint and those who have adopted it or are now using it.

What SharePoint Ads will do in my honest opinion is further strengthen the growth of the blogging community. If anything proves how many bloggers and community members for SharePoint there are out there it is that we actually have a strong need for more services like this one that help members of the community profit. No longer are we referencing organizations, but anyone who uses SharePoint and wants to share thoughts or ideas.

To me any company should see this as an important step and understand the WHY it’s so important.

Having blogs on the company website could bring attention to the company, but lets face it. A blog and the typical creative content of a blog is proprietary to the person who writes it. The author is the one who wants their name associated with their thoughts and ideas. This is why in my opinion the whole blogging in a company hasn’t really taken off. It’s just too personal still. Writing articles are a different matter, but blogging certainly is still a personable experience.

Since it is so strongly independant companies are often interacting in a very limited sense with bloggers. Services such as SharePoint Ads provide a much simpler, easier and more effective way for organizations to get their product or service heard by their target audience. “SharePoint Products+Services for SharePoint Users”

So if you are a company out there. Note this. See how important this change is, and jump on the bandwagon because this methodology for marketing and advertising is the future. Status updates (twitter) are probably next where people get paid based on positive references to products etc, but for now blogging is understood and accepted by pretty much everyone, but it certainly isn’t fully used as an advertising medium at this point.

Anyways I rambled a bit, but just wanted to illustrate how great this was, and hopefully open a couple eyes to why it’s an important step in connecting the community and businesses interested in the same thing.
Richard Harbridge

Understanding Field Controls and Web Parts

March 19, 2009

Andrew just had his new MSDN article on Field Controls vs Web Parts, and their application in publishing sites released on msdn.

If you have, or are planning on building a publishing site this is an extremely important article for you to read as it clearly outlines many of the reasons why field controls may be a better choice than webparts when designing and setting up your publishing sites.

Great work from Andrew on making this information much easier to digest and more centralized,
Richard Harbridge

Development and Design Concepts (How to get to Predictable Development)

February 24, 2009

Today I stumbled upon an old post by Alan Cooper located here:
(Thanks to another blog post on SpittingCAML for bringing my attention to it.)

I want to ask you all a question based on the article and Development/Design Concepts that are debated out there, but before I ask the question I need to give some background:

The article is extremely well articulated and while I am not a fan of necessarily grouping people as one collection or another it does a good job of illustrating some of the deep set challenges of our current Development Practices (I speak of a wide generalization based on what I have seen in organizations I have worked with). The issue described in the article particularly is that of unpredictable development.

The issue Alan illustrates here of unpredictable development clearly describes that the approach to solving them is by better understanding individual programmer objectives or goals and mapping that in a way to the processes we use to create the end solution.

He creates two classifications, builders and designers and explains each. For the sake of brevity I will just quote the illustration here:

The first camp is composed of builders: those programmers who, like the many carpenters and masons who preceded them in history, take a sublime joy in seeing their handiwork take form in the real world where it can be—and is—used and appreciated by others. They may be hammering together packing crates or they may be painstakingly crafting Steinway pianos, but seeing their products of wood and steel assume a tangible form that gets things done in the wider world provides them with a sense of accomplishment and well-being. It achieves their goals.

The second camp is composed of designers: those programmers who, like the many visionaries who preceded them in history, take a sublime joy in seeing complex, apparently intractable problems dissolve in the face of their creative thinking. They may be arranging utensils in their kitchen drawers or they may be painstakingly calculating how to shape a girder to support a mile-long highway bridge, but seeing that the solution they imagine is the best and most efficient one possible provides them with a sense of accomplishment and well-being. It achieves their goals.

Of course, the builders share in the joy of devising clever solutions just as the designers revel in seeing their creations take real form, but if a mutually exclusive choice between the two options ever arises, each will be happy to focus on the type of work that best satisfies his goals.

What I think is important here (and I am trying to be objective) is that the article outlines a simple yet effective way to help improve development processes. The method outlined: By creating designers and builders with appropriate roles and responsibilities that run in line with their personal goals and objectives; the development work and end result will be far more predictable and of higher quality. This quality can be measured as reduced cost, higher morale, and so on.

You can read hundreds of books and articles, and of course this is a heated debate topic, but for me personally I believe that the only way a development process and methodology will be effective is if it works for the actual developers you have on staff.

As an individual developer it is extremely important to know and understand your fellow developers. It is even more important for anyone structuring development practices or managing developers to understand the developers they manage. Knowing their personal goals, interests, and objectives will allow you to assign them with the work that is most suited to their personality and style.

Realistically the ‘builder’ and ‘designer’ is an extremely oversimplified description, but it has value in that it is a separation of developer types under more than one classification. This way there is a greater chance of them getting the kind of work they want.

Let’s think about that for a moment:

  1. What happens if a developer falls under both types? Or seems caught in the middle?
  2. Or if (as is the case in many small development groups) the developer must constantly change roles to deal with the increased demand?
  3. Then even comes the more challenging aspect of:
    Who makes the judgment for which group they belong under?
    The manager? The developer? Co-workers? A objective and neutral testing process?

It becomes a spiral of questions that quickly pulls attention away from the important and easily understood concept that the individual’s goals and personality (regardless of what they do whether it be development, design, consulting, analysis, etc) should have an impact on the work assigned to them and that the only way we can try and assign work is by using classifications.

We use classifications for everything. From our professions (Analyst, Designer, Developer, Manager, etc) to often our personalities themselves (Introvert, Extrovert). These all provide value if they are used correctly.

The great article Alan wrote depicts two interesting classifications of developers which separates them by their goals and interests (or personality).

Hold on a second, I said earlier I am not a fan of grouping people or classifying them, and yet I just described how it is effective? It is effective and works in many situations however these can never be static, and will and MUST change based on hundreds of influencing factors.

You will no doubt need to break each classification down further, or adjust them to match the kinds of developers you have, or adjust them to better suit the kind of architecture and design work necessary for successful projects based on the technology you use. All these reasons and more such as cost, organization style, your own management style, etc will influence how you structure it. In some cases for extremely small development groups it won’t make sense to even have classifications.

So in summary (I know I rambled a bit, apologies) Alan’s article is really fascinating and good because it shows that many other people understand that the personality of developers influences the development process and development design concepts. He also (based on his own situation and experience) suggests two classifications that work for managing and working with his developers.

So the question I give to you is:

What classifications would you use?
The same ones? Or different ones? If they are different why are they different? What is your situation like?

Have fun thinking about it, or applying some of the concepts Alan describes,
Richard Harbridge

Visio Template for SharePoint Wireframing

February 24, 2009

As always I love finding new Visio templates for anything related to SharePoint. While recently I have begun using Mind Manager Pro (from Mindjet and as a direct result of Ruven Gotz’s presentations) instead of Visio in certain situations; I still use Visio for a lot of the workflow modeling I do, as well as documenting architecture diagrams.

If you have stencils for Visio and are used to the tool you can use this template from Erica Toelle to give you a head start on whipping up some wireframes. Even if you are a developer, or analyst and not a designer it might help you sort out ideas with a client on the fly. I know I have done this on many occasions an in some cases just used it to illustrate some ideas to the design team.

Hope this helps you,
Richard Harbridge