How can you establish a good requirements overview for an IT or Web application project? Good question isn’t it?
Over my more than 10 years experience in IT world I have seen plenty of good and bad project specifications, KPIs and requirements. Similarly I have been honoured to participate in quite a large number of initial project meetings, where you actually obtain that information.
How can you avoid confusion, how can you make both meetings and paperwork effective and comprehensive for all parties involved?
Again, this will be my personal observations from two really great teams I was privileged to part of;
They both distinguished few similar patterns in conducting discovery meetings to build up prerequisites and convey project specifications.
I am sure they maybe more, but let me share five today. 5 ideas to make your initial IT project meeting successful;
- Have a meeting before a meeting - My leadership mentor John Maxwell writes about this extensively in His book Leadership gold. He emphasises the importance of getting everyone on tract with what’s needed for a meeting or a project both from technical and human perspective. How do you that? Make calls, meetings and emails well before the meeting to bring people up to speed. If possible get into details as much as you can, use words and illustrations to touch different human senses. As you see - more leadership than technical experience.
- Be concise. Set time boundaries and control them. If possible have one person to keep time track. For example if you agreed on two hours, then after one hour time keeper should simply ask a follow up question: “How are we getting on, are we on line with our meeting plan?”. What about paperwork - documents - same be concise, if you have an illustration use that. Edit it with some image editing software - use arrows to emphasise your personal ideas and thoughts.
- Have a plan - even if you don’t have a plan. What’s that. You may here something like that: “Let’s have Skype chat and I’ll show you by examples what I mean.” Event in this case - make a quick plan, like “Let’s go through my examples for an hour and then let’s have a Q & A session for one hour”. Well quite naive, but it is a plan. For documents; Table of contents - thing I rarely see would do a miracle.
- Know the context. This is one of the most difficult ones to comprehend. In personal growth there is a thing called “Awareness”. What does it mean for technology world? Are you a startup or a well grown organisation? For startups: focus one the essential elements needed for MVP and I am putting an exclamation mark - ESSENTIAL! Startups are limited in funding, so deep digging may get them starving. For larger organisations: Determine all FACTORS; security(can be a complex issue), adaptability and teachability. Development inside a bigger organisation must not only developed but also, you have to integrate it.
- Make a good ending. Funny though but the magic comes in with these simple words: “Are we ok, is that it or you think there is something else we need to discuss?”. For documents - as you share them; A simple followup email with similar question, like: “Do you think we have provided enough information for you?”
Happy meetings and documenting work. I wish this will help you and your teams.