To answer your questions:
1) BCBS stands for Blue cross Blue Shield - one of the biggest health insurer in U.S.
2) the meeting would be attended by PM,SMEs and other analyst with 6 people in all.
3) I was given entity relationship diagram by my PM depicting flow of information b/w entities. He expects me to make a DRD out of it.( after meeting with SMEs)
4)He gave me a ' key project milestones and deliverables' document which gives it a 3 months time. My work( Developing data requirement definitions& then building data flow diagram) is 2 weeks long and then later 'initial requirement gathering' 's time length is to be decided.
5) All i know of , is that he has a project scope and project charter document.
6) I work directly with my PM and unfortunately he travels a lot. So virtually i am left all alone to figure things out.
K
I know what you are talking about. Its just that i volunteered for this project myself. Idiot - You might think. Well i am young (just turned 24 last month) and with the current market situation i did not want to be the first in the firing line by being 'on bench'. I might sound desperate by i have debts to pay. I am willing for a 100 hr work week( and probably my PM knows that) and would do whatever it takes to excel in this project. All i want is a bit of guidance from the seasoned players out there.
I have few options apart from doing well!!!
Hi:
Sounds like management realizes that they have a big integration problem.
You want to as soon as possible identify scope (i.e. the extent of the system). A context diagram is a speciall data flow diagram for identifying scope. It shows the system as one big circle with inputs from and outputs to external entities (other systems, people, etc.) The problem with creating a context diagram first-thing is that someone has to already have the "big picture". And no one ever does. So, what I typically do is create some rough-cut lower level diagrams and then summarize them up into a context diagram.
So, first thing, focus on data flow inputs to and outputs from the system, high-level functionality, and - especially - the data flows between functions. This is not an easy task. People (SME,s end-users - and even most BA's) like to get into the details way to soon. Letting this happen can really derail your efforts. Your job is to steer them away from the lower-level stuff, especailly the implementation details, and guide them towards discussing DATA FLOWS at as high of a level as possible. Make you diagrams as simple to read as possible. Your first iterations will probably be a mess. But, "pretty them up" , and then get back with the users and walikthrough, walkthrough, walkthrough.
Tony
Three thumbs up for the context diagram!
If the company doesn't care enough to spend the time to coach you into the role, or to support you in the first few weeks they must know what they are going to get.
This raises an ethical question of whether you should escalate the problem up the chain of command and force the issue (and possibly be removed from the project.) After all you can be fairly certain that with no proper guidance and inufficient time/resources, you'll just be another failed iteration.
If you do escalate the issue you should come with some solution ideas to discuss (eg more time, someone to help, a different approach to requirements gathering, etc)
Actually, this story has me a little riled. So I have to write more.
There are about a billion articles and studies available on the net demonstrating how critical requirements management is to project success. David Wright (of IAG Consulting) might be able to point you to reseach by his comany on the topic. It says something like 80% (warning: PDOOMA statistic) of project failures can be traced to poor requirements practices.
There is also a stack of info to demonstrate that project managers who make up estimates without consulting the actual 'do-ers' get what they deserve. Schedule overruns almost immediately, which are never ever recoverred.
Maybe gather some of this info together and present it to your PM along with a better requirements plan. After all - he/she dfiniely cares about a successful outcome.
brought to you by enabling practitioners & organizations to achieve their goals using: