As an ECM specialist, you know that every time you are involved
with a project, there are requirements gathering activities. It doesn’t matter
if the project is small, or that “there’s a ton of documentation”. It may be as
simple as writing a document that references previous deliverables to build on
them. Because content processing is in constant flux there is more a need to
not only keep your documents up-to-date, but to keep the non-deliverables going
smoothly as well. What do I mean by “non-deliverables”? Well, I’m glad you
asked:
Here’s the standard list of hard deliverables:
- Charter
- High level Goals
- Budget
- Resources
- Milestones
- High level deadlines based on upper management goals
- Interviews
- Demos of software OOTB capabilities
- Brainstorming sessions
- Goals refined by business group’s focus, rolling up the high level goals
- Requirements
- Traceability matrix
- Functional Specs
- Logical Architecture
- Use Cases
- Test Cases
- Schedule
- Meeting minutes
- Pros and Cons
- Cutover Plan
- Communications
- Training materials
- Etc.
·
I here’s a list of soft deliverables:
- Trust and Presents
- Quality and Inclusiveness
- Dependable and Honest
- Generosity
Let’s look at each of the above “soft” deliverables and how
important they are and discuss why projects can be disasters without them.
Trust
I know this goes without saying, but trust is earned, it is
not a given. Meeting face to face and getting to know the stake holder(s) and
the team is essential. This is a mutual trust. If I say I’m going to do
something, I do it, if they say they will do it, they should do it as well.
Many times a stake holder will not have time to attend all the meetings. In
this case, you have to make sure the stakeholder is delegating tasks to someone
else. You also need to make sure that meeting notes are written and that issues
and next steps are clear to everyone, with follow up emails stating the near
term timelines to get things done. Managing expectations goes hand in hand with
trust.
Quality and Inclusiveness
As you interview stake holders as to what their goals are
and what they expect the project objects should be, you need to make you ask
about whom to include in meetings, who is actually doing the work which will be
automated. Pay attention to detail and use the tools such as Visio to visually
show and review the processes. There is no such thing as a workflow which is
completely done, every time I review a use case or flow on my own or with
members of the team I find new exceptions and new ways to looking at the
process. The quality of your attention and understanding is crucial. Including
as many reviewers and encouraging feedback is also key to the success of the
project.
Dependable and Honest
I am not going to preach about the differences between a
full time analyst and a contractor, but I will say this, that a contractor is
not going to be around for the long run (usually). This means they will say and
do things that get the work done at hand. What about the future of the project?
That’s someone else’s dime. The stakeholders need to be dependable as well. A
project is doomed if the governance of the execution of the project is in flux.
A project manager cannot hold to a schedule if the resources are double
allocated.
Generosity
We all work hard. Going out of your way to make things
happen “the right way” will always benefit the project. We shouldn’t just write
documentation because we have to. We should write it because it will help
during testing, it will help during the next upgrade, it will help you remember
the approaches taken for your next project. Writing to a standard template may
work for a contractor, but if you go the extra mile and write for quality and
give your best, it will show in the project’s success.
