Archive for August, 2009

Configuring Approval in SharePoint

Part 1: Content Approval

I often get asked for advice on how to set up the approvals in MOSS. While this is simple enough, there are some subtleties that you need to be consider if you want to get the most from it.

First of all, you need to be aware that there are two approval mechanisms. These are “Content Approval” and “Approval Workflow”. The first of these is the simpler, and it often meets requirements without the need for an actual workflow. The workflow is more powerful, but is more complex. The workflow mechanism can interact with the simpler content approval mechanism.

In this first article we’ll look simply at content approval, as we need to get a handle on this before considering the approval workflow.

In the second article we’ll look at the approval workflow.

Recommended Setup

If you’re just looking for instructions on how to set approval up, my recommendations are given below.

Content approval of documents and web pages is best combined with major and minor versioning, and requiring documents to be checked out. Unapproved versions are then given minor version numbers, and when a document is approved it is given a major version.

The versioning configuration of your document library should look as follows:

document library versioning configuration

Depending on your situation you may want to limit the number of versions that are retained. This setting won’t affect the behaviour described below.

Users who are able to edit items should be added to the appropriate SharePoint group such as “Members”. Users who are to approve items must be added to the “Approvers” group.

For the rest of this article, I have assumed that the above configuration is in use, although I do cover what happens without versioning at the end.

Content Approval in SharePoint – the Details

You can configure a list (such as a document library or the pages library of a publishing site) to require content approval. What does this mean? It effectively adds another column to your list named “Approval Status”.

With these settings in place, when a user updates an item the status is “Draft”.

item with draft status

Users can submit the item for approval, either

  1. when they check it in
  2. by selecting “Publish a Major Version”:publishing a major version using the item dropdown
  3. or for web pages, by pressing the button on the editing toolbar:submit for approval button

This updates the  status to “Pending”.

Users now get the option to “Approve/reject” the item.

approve or reject on item dropdown menu

Only users who are in the “Approvers” SharePoint group are able to approve or reject the item. Any other user that attempts this will get an access denied message.

For web pages SharePoint displays “Approve” and “Reject” buttons in the page toolbar. These buttons are only visible to members of the approvers group.

approve and reject buttons

Finally, it is possible to have content approval with only major versioning or without versioning at all. If this is done then any changes to an item result in the approval setting going straight to “Pending”, ie there is no “Draft” status and no concept of “Publish a major version”. The “Submit for Approval” button on a publishing page will look slightly different as it also performs a page check in.

submit for approval button

In part 2 we will take a look at using the approvals workflow.

Back to the PointBeyond web site.

The Absent Stakeholder

Your stakeholder has gone missing! A senior executive who holds many budget strings for the whole organisational unit of your corporate firm, he is not answering your emails, not attending project meetings, and since his corporate diary is not visible to you it’s not possible to judge his whereabouts or reschedule to a different slot. He sits in a different building so you are unlikely to see him in the corridor to say hello and remind him of the next scheduled steering group meeting.  But you know he’s senior and busy, so maybe that’s to be expected. Perhaps you are a bit in awe of him and don’t dare call him directly – your one voicemail has gone unanswered so you don’t dare pester him again.

The project is already underway and analysis is getting into full swing. It’s your first large software project and you are keen to impress your VP with how capable you are. Your ultra-busy VP has told you that there is budget for this initiative and it sounds like it has been approved by your stakeholder. You don’t know – you were not there – but you trust her. So far no ongoing issues, you report on your weekly report – on track with analysis and no complaints – the analysts are working hard and future users seem cooperative in discussing requirements. And yet you have this dull, nasty, worried and annoying feeling in the pit of your stomach just thinking of your stakeholder. Why is he ignoring you? It is personal?! Does he not care all the trouble you’ve gone to to get this far? Yet since all is quiet you carry on.

This PM is right to feel concerned. What a potential disaster waiting to happen - and this PM is not really seeing it coming. No news is not good news with stakeholder engagement. The team might well be heading for a project that is stopped and all funding pulled, or they could end up deliver something no-one wants, or there could be a massive row with the sponsor about the current lack of proper engagement.

I’ve seen projects in that boat and it never ends well. Money and time gets wasted, reputations suffer, relationships between organisational units get strained. Deal with this emergency situation immediately: you’ve lost the attention of your project sponsor and it needs to be regained at all costs. Or perhaps you never had the right person; the correct senior executive must be engaged asap.

Communication and engagement are two cornerstones of a successful project. Get these right and you are well set for the rest of the process. Chances are that faulty or absent communication, as well as shoddy stakeholder analysis, are at the core of many troubled projects.

There are several things a PM must do to rescue the situation:

- Communicate: Check you used the right communication methods with your stakeholder. A phonecall is far better than an email. A face-to-face meeting is far better than a phonecall. Call your contact and schedule a meeting in his diary via his PA. You will find that a meeting might well achieve where a dozen emails failed. You should agree ground rules for working together to ensure project success.

And whilst you are at it, check that you know and use the best way to communicate with all your project participants.

- Engage: Review your stakeholder engagement map. If you don’t have one already- write it up. It is essential to know your stakeholders – have you got the right people involved? What do you need from them, and what do they need from you? Are they going to assist you or block your progress? Do you need to influence them to convert your blockers to supporters? 

Map it all out and link your stakeholder mapping analysis into your communication plan.

Finally,

- Recognise potential issues: Tell your manager about this problem, don’t sit on it until it’s too late.

I am not suggesting that you escalate to get your boss to deal with the problem instead of yourself, but in some hierarchy-conscious organisations someone might be seen as too junior to deal with senior executives and gets ignored. It’s a terribly unprofessional practice, of course, but it’s something to be aware of.

Ksenia Woodgate

Back to the PointBeyond website

Project management with a healthy degree of paranoia

Whether or not one is a natually paranoid person only one’s closest friends and family can really judge. However when it comes to overseeing projects, a PM – in my opinion – has to develop a healthy degree of paranoia, regardless of their natural predisposition. And I think that’s the right – no, the essential – attitude to have in this job. Let me explain what I mean by that.

It’s really a combination of things: attitudes and qualities such as “close attention to detail”, “leaving no stone unturned”, and most importantly, “never making any assumptions”. This does not mean the PM has to do everything on a project and be everywhere at the same time, constantly breathing down people’s necks - that would clearly be unrealistic as well as annoying and unworkable for the team as a whole. PMs can and ought to delegate tasks. But even with delegating, a PM must invest a serious amount of effort to establish a reporting feedback loop and an accountability framework which then creates an environment of open, transparent and constant communication across the team and with the stakeholders. And when not delegating, a PM must make it their business to fully understand the subject matter or seek reliable expert help to ensure success. It’s common sense to all good PMs.

Project management is as much as art as it is a process. Much has been written about the process aspect of project management, and there are excellent tools available for PMs. However a part of the art of successful project management is to have this gut feel, this instinct for  sensing potential future trouble when there exists at least the tiniest lack of clarity about something the team is engaged in. And a healthily paranoid project manager should realise that if there is a little bit of scope for something going wrong as soon an a little gap in communication opens up, things will indeed go wrong given half a chance. Any unchecked assumption can blow up in your face.

So working with this instinct, a project manager should be continuously checking and validating in detail any assumptions they might have made, confirming everyone’s understanding of tasks and deadlines,  ensure sensible and pragratic process is followed, bringing people together to collaborate better, and thus work on ensuring total clarity throughout the project lifecycle.

The other day, a client with whom we’ve been working for some time asked us to proceed on a piece of work by sending me a quick note saying “please commence the work”. Some specification documents have been written, and a summary of estimated costs has of course also been presented in the past. But the client has not signed off on these in an explicit way (we are not using a document approval system with them at this present moment).

To a project manager, this lack of an explicit approval should be a concern – and my paranoia, my gut instinct tells me that this needs to be sorted out. Even though documents have been swapped at the same time as the informal approval, such a situation can be misconstrued in future and perhaps someone could claim that sign off has never been given. We would not want to risk such a situation developing, so – call me paranoid – I am seeking to have a more formal written acknowledgement of my documents.

And maybe this is a bit formalistic – and perhaps even a bit annoying to our customer whom we know well and for whom we’ve successfully delivered projects in the past. But as long as everyone is clear on the implications of this situation and the risks that both parties expose themselves to, then better and clearer communication will follow and I think we will get the project kicked off properfly in the very nearest future.

You can call it the art of project management; or you can call it common sense.

Ksenia Woodgate

Back to the PointBeyond website

Presence on SharePoint People Search Results

Seems that even if you turn off presence on an application (in central administration/application management/web application general settings/person name smart tag and presence settings), the profile button and menu still shows up in search results.

Is easy enough to remove by editing the page, modifying the people search core results and launching the XSL editor. Remove the whole <xsl:choose>…</xsl:choose> element immediately below <span class=”psrch-Title”>

Back to the PointBeyond website

ASP.net Connectivity to SQL Server 2008 SP1

Have been getting the following error in SharePoint from a custom web part which tries to connect to a SQL Server 2008 SP1 database

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)

Spent several hours diagnosing the problem. The solution is as follows

Start SQL Server Configuration Manager. Click on “Protocols for MSSQLServer”. Enable TCP/IP (which is disabled by default).

Back to the PointBeyond website

SharePoint, Kerberos and DNS CNAME Records

It seems that some versions of IE create the wrong SPN when accessing a web site via a CNAME record. More info at

http://support.microsoft.com/kb/911149/en-us

To be on the safe side, use A records in DNS to point to your SharePoint site.

Back to the PointBeyond website

Cannot Start Search Service on Farm Servers – More Kerberos Fun!

On a normal SharePoint deployment I get all the web applications (central admin, SSP admin, My Sites and the portal site) working using Kerberos by setting SPNs, configuring the applications, and verifying everything is working okay by using Kerbtray. Similarly I set up SQL Server for Kerberos.

However one thing has always bothered me slightly: What about the web services of the SSP?

In Martin Kearn’s very thorough article he correctly states that you enable Kerberos with the following command:

stsadm –o setsharedwebserviceauthn –negotiate

On a single server farm this appears to work fine.

However if you perform this step on a multiple server farm, and then try to start the MOSS search service on subsequent servers in the farm, it will fail to start, giving an authentication error.

The problem is due to the Kerberos configuration for the SSP not being complete. Of course, how could it be, because we never set any SPNs? The solution is that there are several additional steps needed to configure Kerberos for the SSP. These additional steps can be found here:

http://technet.microsoft.com/en-us/library/cc263449.aspx#section14

Also I have also found the following document to be most useful when troubleshooting Kerberos errors:

http://www.microsoft.com/downloads/details.aspx?FamilyID=7DFEB015-6043-47DB-8238-DC7AF89C93F1&displaylang=en

 

Back to the PointBeyond website

Content Query Web Part, Target Audiences, Additional Filters

Running MOSS 2007 SP1 with infrastructure updates. Have defined various audiences including one “New Products”. All normal targeting of content using the CQWP is working fine and as expected, however…

On one page we want to show all articles where the target audience includes “New Products”, regardless of whether or not the user is actually in that audience. The CQWP appears to let you do this, by

  • Selecting the content type we wish to show, as normal
  • Not selecting “Apply audience filtering”
  • In the “Additional Filters” section, under “Show items when” selecting “Target Audiences” from the dropdown, selecting “is equal to” or “contains”, and then putting in the name of the audience, “New Products” in my case.

However the bad news is that it simply doesn’t work. No items are ever returned with the filter set.

Back to the PointBeyond website

Agile development – on lack of trust as a roadblock

Many IT organisations have faced a question whether or not to develop using Agile as part of their change management process. It has its own well documented merits – such as ability to empower and motivate teams and increase their throughput, as well as deliver a product that meets the customer’s needs very well. A highly motivated team is also more likely to display a greater ability to innovate – a winner all around!

As a project manager reasonably new to “Agile with Scrum” – we are keep to use it at PointBeyond and we tried that in my previous jobs, occasionally with somewhat mixed results – I wanted to share my own thoughts on the suitability of Agile to organisations’ project management processes.

It seems a good idea to carefully evaluate whether or not to adopt Agile, and to what degree to adopt it, on a case by case basis. There are places where a traditional Waterfall approach could still work. In others, Agile can be of huge benefit. It depends.

From my own experience, I can see two areas where Agile and Scrum might not work all that well. Both cases relate to organisations with cultures that are more regimented, and where trust can be an issue.

The first case is where a customer needs to fully understand the end deliverable before signing off on the dotted line to commence the project. So we are talking about a customer who is fairly inflexible in their approach. To receive a go-ahead to actually start building software, one would then need to put in place a comprehensive functional specification – which will be arrived at after a full-on analysis and design phase.

Of course, going Agile does not mean that the functional specification is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. But not all customers will grant such a degree of artistic license to the project team. And hence it can also be a question of trust in one’s professional ability, judgement and skill – is there enough of it between the customer and the vendor? Can the customer “let go” and empower the project team to work out the smaller details using a suitable Agile methodology as the project carries on, or will every question need answering in advance?

The second case is where an organisation’s senior management interferes with the Scrum process, perhaps wanting teams to achieve unrealistic targets and add to its list over and above what teams say they can do – or maybe insists on changes of priorities at short notice and still expect excellent results.

Such an approach can be destructive for any team trying to implement Scrum, as it will cancel the efforts made by the participants to work out their own capacity and commit to work on their own initiative and own understanding of their skillset. Senior management must fully buy into the Agile process and remain strictly at arm’s length. If it does not, the process will not work efficiently and result in lesser motivation and decreased productivity.

The Scrum process allows for priority calls to be made – but only at the start of each Sprint. If, half-way through a Sprint, serious external circumstances cause a massive shift in priorities rendering the current Sprint a total waste of time, the Sprint can be stopped – and this is the only time this is allowed. However if an organisation tries to change priorities half-way through a Sprint by introducing new key items into a committed iteration, whilst Scrum masters allow this to happen under pressure from management, the process can break down. Needless to say, this causes stress to all participants and often does not get the item done on time anyway.

Yet again, we are talking about trust. This time – in implementing Agile – it is between senior management of an organisation and its Product owner, the Project team, and the team’s Scrum Master. When an organisation fully empowers its employees to deliver (whichever change management method is preferred) and gives them all suitable tools to do so, it will have the greatest chance of success. And trust in it’s teams is a huge step towards such empowerment.

Ksenia Woodgate

Back to the PointBeyond website



Follow

Get every new post delivered to your Inbox.