Lessons Learned: A Project That Had Few Defined Requirements

The end of the year is not only a good time to reflect but also to perform that ever so important part of any Project Mangers role ... Lessons Learned.  Perhaps the most important lesson I learned this year involves a unique project I was tasked with completing.

I was assigned the huge challenge of a Designing a SharePoint solution for a company wide intranet, including a solution for the PMO. The PMO solution needed to include a repository for project documents, confidential financial documents and the usual project inputs and outputs - issues, action items and risk lists.

The Problem:
This was an internal project funded by overhead, not from an external client or vendor source and stakeholders wanted it done without much time or input from them. They wanted it done right and it had to work for everyone. 'Everyone' meant, HR, Development, Finance, executives, remote and in house developers, too.  Without requirements, some of the dilemmas I encountered included:

1. No defined start and end.  
2. I could not get stakeholder sign-off prior to development.   They were not directly involved and therefore would not sign-off on milestones involving resources or infrastructure.
3. Each project was managed differently having different inputs, outputs and levels of detail, so project level requirements were all over the map: Some projects needed more structure and others needed less. Some projects were so quick they were over practically before they were initiated.  

I decided not to ignore the quiet stakeholder as also mentioned by Kiron D. Bondale's Blog and requested approval for internal department work spaces. They got approved with sign-off on Security.

The end solution was robust enough to satisfy all projects that could be implemented quickly and expanded on later. How did I get there?

First, I established the basic structure and needs analysis:

1. Security definition - Who needed to access what, what was confidential, group based or individual based?
2. There was a need to store Documents, Secured Financial Documents and Lists.

Then, I analyzed what was needed for an intranet. I asked the question 'What is currently being utilized?', 'What needs to be recorded?' and I performed business analysis and process analysis for each functional work area.

Solution:
A phased Intranet with project work-spaces for project document storage and project status snapshots:

• MS SharePoint 2010 with Template and Workflow features for each department. 
• New work-space creation procedures were implemented for each active project.  
• MS Project was used for Resource planning and plugged into SharePoint for stakeholder reporting.

Compliance and adherence to guidelines brought light to using templates for lists and document repositories for all site elements.  I further worked the requirements on a need by need basis from there to satisfy as much or little needed for the specifications and requirements at the project level.

I learned to be wary of quiet stakeholders,  not to let pressure from the business take away from the current deliverables, and quality should come first above a rush to market with a solution that is not sustainable or configurable. The bottom line is to not allow your project to be under-defined, unstable or runaway.