One of the most important factors for IT project planning success is relevant user input. As I mentioned in my previous blog, failures in proper project planning are really opportunities. Relevant user input is one of those opportunities to improve project success.
User input, better known as “project requirements” or “defined statement of work” is the heart of a project. The average requirements document for an IT project is over 100 pages and changes up to 20 times prior to stakeholder acceptance.
Managing the user input process well is critical for IT project success
Many organizations find it difficult to create comprehensive user requirements and I believe it is because they do not invest the time up front to really examine exactly what the problem is that they are trying to solve, how best to solve it or how it will affect all of the stakeholders in and out of the organization.
Typically, requirements are drafted by one person or a small group in relative isolation deciding what will be good for everyone. While this method seems efficient as it bypasses time consuming and challenging meetings that are required to draw out the real requirements, in the end it can be very costly.
The fact is this: If you don’t take the time, you will not develop good user requirements. If you do not have relevant user input, there will be scope creep. Scope Creep is defined as – “Adding features and functionality without addressing the effects on time, cost, and resources or without customer approval” — PMBOK ® Guide Third Edition.
There is a famous saying a wise man once said: “garbage in = garbage out” (GIGO). GIGO is defined as “the idea that in computing and other fields, incorrect or poor-quality input will produce faulty output.”
To avoid GIGO, it is not enough to simply ask for user input. The IT project plan must focus on the relevance of the user input by addressing:
- User needs, workflows and user environment
- Test and evaluate the user input
- Fully engage the users in the planning process
- Set the performance objectives based on user centric requirements
Without relevant detailed requirements there will be extra work, extra resources used, and frustrated stakeholders. Here are some basic steps that will improve the requirements gathering process:
Start out with the right people (Business Analyst) gathering the requirements improve the relationship between the business needs and proposed project deliverables. Draw a picture if possible. Continue through until a detailed work breakdown structure (WBS) is developed. This will help a great deal to develop a valid schedule and budget.
Based on many battle scars and years of experience, I am convinced that without investing the time in properly defining detailed user requirements, IT projects will fail. Define the requirements up front and avoid the dreaded, “What’s this? This isn’t what I wanted,” comments that strike fear in the hearts of project managers and drive the project cost and time line off the rails.
To avoid this from happening, we need to understand and realize that the best solution for one stakeholder maybe the worst solution for another. Recognize that user requirements need to be negotiated so that they best fit everyone. Without going through this process first, creating project plans, budgets or scope is a waste of time.
Why is user input important?
- If “users” have real input into creating it, they will more readily embrace the new product or service.
- The “customer,” that is the entity funding the project, will realise the benefits through rapid adaptation by the “users,” ostensibly their client.
And finally, the most important reason to get quality user input from an IT project planning perspective is because everything else in the project management process flows from “the project requirements or statement of work.”
If you get this right the chances for your IT project plan to succeed improves greatly.
My next blog will focus on how corporate culture effects IT project planning. I will make suggestions of improving the plan and increasing project success.