Showing posts with label consulting. Show all posts
Showing posts with label consulting. Show all posts

Thursday, June 24, 2010

Out of the box Sharepoint Workflows

As a project manager, I’m often faced with the problem of how to deal with configuration management, which is how we make sure that everybody is on the same page. I typically like to use a content management system to handle this issue. For my current project, I’m using Sharepoint, which also has some nice built in collaboration capabilities.

There are two out of the box workflows on the Document Library: “Approval” and “Collect Feedback”.

Both work pretty similarly, and for general document collaboration they work pretty well.

When you get a document to where you’d like to gather feedback, you can fire off a Review workflow by going to the workflows page for the document:

This will take you to a page that displays the available workflows (will also display any that are in progress):

Choose the “Collect feedback”  workflow and it will prompt you for who you’d like to review the document and a message that you’d like to send. You have complete control of who you pick, and you can also cc people if you just want to keep somebody in the loop:

Once you pick the people you want to review, assign a due date, and click the “Start” button, the workflow is running.  The people you assigned the task to will get a notification that asks them to review the document. It includes your message, and links to both the document and the workflow tasks (I assigned this one to myself):

As the creator of the workflow, you’ll also get a message for each reviewer you assigned that has the link to their task:

Note that the tasks are stored in a SP library called Tasks, and if you click on the “Edit this task” button, you’ll get the form that lets you provide feedback:

This is where you would give feedback that doesn’t need to go into the document. It also allows you to reassign the task if you aren’t the person who should review it (by default it will assign back to the person who assigned the task to you, but you can also use it to reassign to somebody else):

Once the workflow is running, you can see the status at a glance by going to the workflow page again:

If you click on a workflow, it will show you the current status, and you can update individual tasks:

This takes you to the Task in the Sharepoint “Tasks” library (you can get there by clicking the “Tasks” link above) and a web version of what you see when you click the “Edit This Task” from Outlook:

If you want to see all of the outstanding tasks you can go to that library by clicking on the “Tasks” link on the workflows status page (above):

Tuesday, January 6, 2009

Consulting Can’t Scale

I was talking to some friends last night about how we have a nice team of consultants that could do some really interesting projects, when I was reminded of some lessons I learned working for a small consulting firm.

During the dot-Com explosion, a small consulting firm couldn’t hire people fast enough, and it was easy to cherry-pick the jobs that made sense. When I first joined the firm, the focus of the team I was on was to take on full projects for companies that were having similar problems (nobody could find people, so they were willing to have outside teams of experts help them invent their core business). During this period, our biggest problem was not having enough people to take all the cool projects that were coming our way, so we never even considered placing less than a full team on a project at a client site.

As the dot-Com explosion became the dot-Bomb implosion, we were (like most consulting firms) faced with a different problem. There was nothing in the pipeline. Worse, the company had spent a bunch of money on things they thought they needed to do to go public (like building an ASP hosting service) and taken money from investors, which left the management with difficult choices to make.

There were lay-offs (mostly sales staff), and cut-backs. And naturally, the business model changed, since to keep the doors open it was important to keep everybody billable. So we placed people wherever we could, which meant a lot of “body-shop” type of gigs, where we were supplementing people to projects. This, combined with the layoffs, meant our bench was thin, which in turn meant we could no longer handle full projects. Eventually this resulted in the company turning to a policy of “if you’re not billing, you’re not getting paid”, which resulted in a lot of the more effective consultants (like me) leaving the company.

The most interesting thing about this to me is the fact that there is some critical mass of consultants that you need to have in order to do project based consulting (where you “own” the project). You need enough people so that you have teams working all of the time, and to be able to support the teams between engagements. If you aren’t large enough (or the economy is bad enough), you can end up trying to keep the firm going by placing individuals, but that will almost certainly reduce the number of projects that you can do (since now that critical person is no longer available for the team).

In fact what we saw was that the “body shop” approach, kept the most critical people extremely busy at the expense of those who were not in such high demand. Project managers, architects and DBA‘s were placed, and so when a project came along, were not available for a team based project. And of course the vicious cycle would be that since we couldn’t take these projects, the people who weren’t being placed would leave, which inevitably led to other people leaving …

Eventually the economy recovered (as did the consulting firm), but I’m thankful for this magnifying lense on how difficult it really is for a small consulting firm to be successful.  It almost always comes back to focus, except of course when it comes down to survival.