Blog of a Boston-based IT Consultant

This has been a challenge. I am involved with a 2 million dollar project that is under tremendous time constraints. The project itself is a MOSS (SharePoint 2007) project, and it is very stressful because of a variety of reasons. Let me enumerate some of them, if only to vent.

1. This is not really a SharePoint project. SharePoint vendors were solicited, came in, did a good job at convincing people, and maintained momentum. They did a great job. The company hiring them might not have done a great job.
2. The PMO in place at this organization was led by a person who did not know what a Use Case or Risk Assessment Document was. I did not know this when I came on as a consultant and was in fact told that there was a brand new methodology in place. I saw it, on paper. It looked like a cross between RUP and something custom (that I assumed was related to Health Care project milestones - since this is a Health Care company). I should have asked more questions, but the truth is, I like this organization and believe in what they do. Whatever the state of their PMO, I want to be involved.
3. A methodology on paper is very very VERY different from a methodology that has been accepted by the organization and is understood. We have this paper methodology, but there is very little understanding of the WHY.
4. This project involved building a system. A big System. The system should be capable of producing templatized “child” websites that share a common feature base but can have these features turned on/off and be able to receive totally custom modules when called for. It should also incorporate workflow management, document management, and CMS-related functionality. The team decided upon SharePoint 2007 before I came aboard. I did not know that
   • There was no official signoff on SharePoint
   • No Risk Assessment had been done
   • No Cost Analysis had been done
   • No forecasting had been done in terms of cost or staff or technology
   • Although meetings were taking place and money was being spent on this project, it has yet to be signed off on. There is no Project Charter. Not even a Statement of Work.
5. Development and Scoping of this system has been outsourced. The theory (the incorrect theory) was that it made sense to have MOSS specialists do the Requirements Documentation. The outsourced agency has spent 2 days on-site and come up with a “High-Level Requirements Document.” This document has cost the company $20k. It will reveal nothing we do not already know. The consulting company has ignored internal documentation regarding the “child sites” and has instead focused MOSS. Here is a typical conversation:

Us: “We want the breadcrumbs to reflect their MySite at the top level, and we want content to open within the body of the MySite page.”

Them: “Well, you can’t do it quite like that. Let me tell you how SharePoint does it, and why it’s really better this way…”

Us: “Okay, well… let’s run this past Design, Bill, Sarah, Ed, Development…”

So of course, this MOSS spec is being built by an outsourced agency while we run around internally and have meetings to see if we want them to do what they are already *doing*

There are several obvious problems here. Early on, I raised the issue of a Risk Assessment. I was told that we needed to wait until the system was scoped. I persisted, saying there were risks inherent in the technology and the engagement with the consultant as well as the definition of the project as a whole and the fact that there was no Project Charter, Communications Matrix, or even internal Project Code. T

Now, $60k has been spent on a SharePoint 2007 document. Not a Requirements Document. They have produced a proposal, and we have paid for it - which is fine and dandy, but it is a proposal for a MOSS solution, not a technical solution. It is not a PORTABLE Requirements Document. It is a very high level SharePoint blueprint.

The platform and child sites must be up and running by February.

What I have forgotten (and this is a bad thing) is that everything the consulting company stipulates that is dependant upon a specific techology begs an Assumption that needs to be documented. It seems like an awful lot of work has been created by going down this path. Not only is our documentation biased, it is unsupported and requires more documentation. Lots more documentation. Makes you ask, “Why do we do all this documentation?”

At some point, it is a matter of CYA, yes.

But documentation is supposed to be USEFUL. It is supposed to have UTILITY. If people create documents and the documents are not scrutinized, used to make business decisions, used to shape solutions, or used in some way, the PM/BA is wasting their time. This consulting company is creating a lot of wasted time. Time would be better spent doing real discovery, real Requirements Definition for the “child” sites, real analysis upon common features, the deltas between them, and real cost/benefit analysis. Earned Value Analysis. Present Cost Analysis. Common Sense Analysis. This all should have been done a long time ago, and yes - so what, it isnt done… do it now. However, there isn’t enough time. There isn’t enough time to do this project correctly. A major deliverable - the completed platform and child sites - is Feb 1, 2008. That is 6 months away.

So this is about damage control as much as it is about being hyper-aware of this road we have chosen and the obstacles, costs, and other gremlins that lie in wait.

This post was a venting session and I don’t expect people to get much value from it.

As I said, I am being utilized as a technical consultant on this project. I am to ensure that the PM is covering herself in regard to the technology aspects of the project.

We will be okay. It will just take a lot of hard work, intense conversations, and long nights of me writing dot notated documents and forcing people to sign off on them before the consultants build *anything*.

Josh Milane

MIT Technical, Boston

MOSS, Project Management | RSS 2.0 | Comment it , or trackback this post.