There is a fairly prevalent situation that occurs in which technology savvy team members are asked to transform a half-baked idea/concept into some digital solution. Unfortunately the non-technology folks are under the false impression that the technology itself (like a magic wand) will correct poor planning, faulty assumptions/bad logic etc. This can cause strife and lead to friction among team members.
How do you combat this problem? There are a few simple things you can do that help minimize (not prevent) this from occurring:
- Require that a “project sponsor” be assigned to the business side of the project.
It is key that the project has one main sponsor who is the lead and has overall responsibility for project success. If one is not evident, ask that one be appointed before moving forward. The sponsor is vital because you will need a “go to” person for various circumstances and without one lead you are subjected to group decision-making which is ill-advised.
- Start the project planning process with a “concepts discussion” meeting with project sponsor.
Prior to the formal requirements gathering, it is beneficial to get an “elevator pitch” from the sponsor that basically answers the question “what are we trying to do here?”. It is surprising how often the sponsor cannot clearly put into words the concepts of what they are looking to accomplish. If the sponsor can’t do this – the project is doomed from the start. Send them back to think it through and schedule another meeting when their thoughts have matured.
- Ask the project sponsor many questions up front (in writing if possible).
This may sound quite obvious, but it is surprising how often this does not happen. It is a crucial error to “get started” on a project without complete understanding of the requirements/framework. Make sure the sponsor understands that pre-planning is necessary and the project will not start until sufficient background information is obtained.What you are seeking is a commitment on the part of the project sponsor to provide adequate background prior to starting the project. Just like you wouldn’t ask a builder to start work on your dream house without plans – same applies here.
Here are a few starter questions:
Who is going to be using this digital tool? How will they access/find it? What do you expect them to accomplish by using it? (If dynamic, who is going to be responsible for maintaining the data that feeds it?
- Don’t fall into the trap of estimating timelines too early.
Eager project sponsors will try to solicit a time commitment for the project, well before the requirements gathering is in full swing. If asked for a completion date before the requirements are complete, there is a very simple answer to the inevitable question “When will it be done?” The proper response “I cannot tell you when until we know “what” it is and “how” we will build it.
While you cannot immunize your team from getting involved in misdirected projects, proper due-diligence on the font end can help minimize the number of times you have to re-group and restart the project.
Proper project planning prevents poor performance!