An IT Project's Soft Deliverables

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.