I work in E-commerce Start-up, where clients are not familiar to define their requirements in documents / neither as any written form of communication such as e-mail. They pick up the phone anytime of the day & communicate their requirements / ask clarification to project manager and instaneously expect answer at that moment. This tradition in many instance led to wrong intrepetition sometimes by the team / manager and no written form of communication has led to gap in understanding.
Could you please guide me in dealing with such situation Saving Changes...
Now a days this is becoming common and that can also be seen by increasing adaption of Agile based or Kanban based approaches. You may get some ideas from Kanban, here is one small free online program on same : https://www.izenbridge.com/kanban/getting-...re-development/ Saving Changes...
Mike DewingSenior Project Manager / Program Manager| MLD Holdings Ltd.Surrey, British Columbia, Canada
Sounds like a little education on processes is required. Even using Agile requires to add items to the backlog and have it prioritized accordingly so it can get into the next sprint if that's appropriate. Saving Changes...
Deepa KalangiManager, Program Management, Author, Trainer| CVS HealthCharlotte, NC, United States
Hi,
You have not mentioned whether it is Scrum or Waterfall methodology.
With waterfall: When you get random requirements, you teach the process(yes, if you have to repeat, reaffirm, please do, that is the duty of the PM's), but never let them say the requirements verbally. Show them the document, ask them to write it down and go through the approval process(whatever you have and is applicable). Talk patiently and repeat the same approach to anyone, everyone, any number of times.
With Scrum- Since there is a different approach to requirements, not so formalized like waterfall, but still has a requirements document, show them the document and maybe add a different section..to discuss- requirements(something of that sort) and use you last 5-10 min of your daily scrum calls(yes, outside of scrum process, but best time and place as you have these daily and the whole team participates). Don't let it go over, schedule separate sessions based on quick evaluations of these reqs.
Hope this helps. Saving Changes...
Mohamad FararjehProject Management - Electrical Engineer| San Francisco Bar Area Rapid Transit (BART)Santa Clara, Ca, United States
What I suggest is for you to take the initiative. What I did, for these situations, is to generate a document (name it whatever - new requirements, contract change order, change request, addendum, ...etc), then capture the new requirements, and email it, fax it, or even mail it back to him as a change order. this way, you have a formal document to reference.
Otherwise, you are opening the door for dispute of who said what. The bottom line, the requirements have to be clearly stated in an approved and signed document. This goes for new requirements or an existing work under contract. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Project manager is accountable for project requirements, not for product requirements. So, could you clarify what type of requirements you clients are stating? Saving Changes...
As has already been said here, it is up to you to write down the requirements transmitted by phone, including the date and the name of the person who formulated each requirement. You could then prepare a sort of "call minutes" where you list the recorded requirements and send them by email, requesting written email confirmation. This could later be useful in case of litigation.
Ultimately, the best way is to compile the requirements into a document and make the customer sign it. An email confirmation is a good start that should be consolidated by the signature of the requirements document (as mentioned by Mohamad Fararjeh). This is practical in a waterfall methodology where all requirements are defined in the beginning and are not supposed to change during the project, so the document could contain all the requirements. However this is less practical for Agile methodology, as requirements might evolve over time. In such a case, it's probably easier to stick with email confirmation and make the customer approve the list of requirements that are going to be implemented at each iteration. Saving Changes...
Thanks for all your guidance. At present, I'm practise to write requirement notes which was communicated verbally to me and drop mail to stakeholders of the project & confirm my understand / discrepancy & later I prepare requirement document & share the same for their reference. As you have rightly suggested, this has helped me in many cases, where one of member in client team denied that such requirement exist & I came with evidence of the same. Saving Changes...
Drew CraigSr. Agile & Product Coach| VanguardPhiladelphia, Pa, United States
Like Mike Dewing stated, "Sounds like a little education on processes is required. "
Creating and implementing a formal process around how the team is to work will set the expectation for both team members and customers. In time, if the process is clear, concise, maintained, and followed, things will improve. Saving Changes...
Hi Sharath, you may continue using requirements notes for reference. But make sure to conduct 2 calls a week to go through all such notes and get confirmation over the call.
Setup a practice like unless confirmed over the requirements call, we cannot go ahead and analyze. Once you setup this practice, the habit of providing requirements over the call would definitely be reduced.
It is a pain to educate the customer and to setup a process. But it would be worth doing that rather than continuing with messy things. Saving Changes...
