One of the biggest challenges as a consultant is to be able to navigate through the waters of ambiguity and deliver high quality deliverables that meet customer expectations. In my current role as a web architect, I was given a one page email as my starting point that basically at 100,000 feet said “give us a new architecture for our website”.
Where to start? At the beginning of course…
That’s where a charter comes in to play. I learned this lesson from a previous job where requirements were very vague. Even with frequent updates to the business, not having that initial roadmap for the project was seriously detrimental in the following ways:
- Many business members had totally different perceptions on what I was “supposed” to be doing.
- I had no way to manage expectations with ever changing requirements.
- Measurements of work effort completed were non-existent since I didn’t have a baseline to start with.
- Goals???? What were they, and how was I to accomplish them.
- Most importantly, how could I stay on task, if the task truly hadn’t been defined.
In my career spanning many different companies, I have yet to see great requirements given to the outside consultant or vendor when they start work on software projects. Many times, it starts with a napkin drawing that is later used to clean up the mess. Being of a lean IT mind set, I don’t want to see a hundred page spec to solve a business problem, however, a clear, concise outline of the problem at hand would suffice. That’s where a charter comes in for me.
Simple, simple, simple. This should be 1 to 2 pages at the maximum. Think of it like refactoring methods. If it is more than the screen, there is probably too much detail that needs to come out in another document. My version of a charter contains the following:
- The problem to solve – To me, this is the vision statement for the work that needs to get done. No more than a paragraph or 3 to 4 bullet points, take your pick. Identifying the problem at the root cause is essential. If this can’t be done, maybe the project should be to identify the root cause.
- Goals – These goals should cover what should be accomplished by tackling the root problem. Bullet these points, and try to come up with no more than 5 or 6 goals. Too many shows a lack of focus on the problem. A good way to accomplish goals is to identify the issues caused by the problem and Pareto chart these issues in order of importance. Goals should be SMART(specific, measurable, attainable, realistic, and timely.
- Measurement of Success – How do you validate that the work you are doing is going to be successful. All measurements should be simple and concise, leaving out any ambiguity. One of the best ways to work with measurements is to display them where they can be reviewed by anyone walking by. This ensures that you stay on target also.
- What is out of scope – Put down in writing what will not be covered in solving the problem. This is very useful in managing expectations.
- Milestones – I am not truly a big fan of this, but most companies where I have implemented charters have asked for high level milestones.
- Key players – These are the persons involved with the project in some form or another.
- Sponsor – Identifying this person(s) is key. They should sign off on the charter, because it is their direction that is key in determining a successful business outcome.
- SME’s – These are the experts initially identified to help solve the problem. One thing that I have found to be helpful is to get these individuals from the trenches and not management. Most times this is a struggle, because the persons are perceived to be too valuable working.
- Any other team members that will assist in solving the problem.
It sounds simple enough, however, charters involve a lot of thought and effort on key members. Your thoughts?