I work in a company that has a PMO that is relatively new. There is some discussion about who should be filling out the project management documents - the project manager, or the business. Has anyone had experience with either method? Pros and cons would be helpful. Saving Changes...
We have the PM fill out all documents with input from the business side. The "pro" of this is that the PM does a complete job whereas often times our business folks hurry through it. We haven't had any "cons" with this approach so far. Saving Changes...
Anonymous
Thanks, that's the approach I was hoping to hear (and one I'm familiar with from experience at previous companies). Unfortunately our PMO is trying to avoid conversation and have the business fill out the docs - no interview process, minimal PM input. Any advice on how to discourage this or educate the PMO? It's very close to becoming standard policy, and I haven't yet been able to find a way to convince the PMO that this is a bad idea. Saving Changes...
Anonymous
That's interesting, usually it is the PMO driving it the other way! I doubt you can change their minds on this. But, you might be able to sell the idea of having a process step or checklist for "PMO process improvement suggestions". That way, if the PMO approach of having the business fill out docs with minimal conversation and PM input doesn't work, actual experiences and observations can be served up in the form of recommendations and hopefully reviewed and acted upon as appropriate. Saving Changes...
Interesting question because it has been asked. I've been working in IT for @25 years. I started in IBM and it went from there. I've held virtually every role in a SDLC. The end users - the business users - are the right people to write the business requirement. The problem is that they are just that - end users and often do not know how to write business reqs. That's where the business/requirements analyst comes in. They exist to help the user determine what it is that they want a.k.a. what are their business requirements. The requirements go in what is hopefully a fairly standardized template that guides the user and B.A. to writing a clear set of requirements that state What it is that the end user really wants.
The business knows their business but they don't know what's required in their document downstream so us system folks can work on effectly implementing their reqs. Yes, the P.M. guides and controls the process as requirements are part of any SDLC (including bug fixes) That's the B.A., Q.A., process person, and P.M. part of me typing.
Yes, the P.M. fills out the P.M.-related docs but those are schedules (created with team input), project plan documents (or S.O.W.s), estimates, etc. Hope that helps. If anyone is suggesting that the PM write the requirements, I totally disagree. Saving Changes...
Anonymous
S. Birnbaum, I agree with your suggestion in part. The gap is where you're working with a business that has no BA role. If the PM isn't willing to create the conversation - the back and forth necessary to get the requirements identified and scoped out correctly - then is it really going to be effective to have the business fill out the docs? In an online/web project, many of the requirements are technical in nature and the business will be unfamiliar with what is required. How does a company move from a broken process - where the PMO is shutting down communication with the business and there are no business requirements analysts to assist - to a process that works? Saving Changes...
Hannah WolfSenior Program Manager| UbisoftSan Francisco, Ca, United States
Another approach to take with this is citing the widely available statistics on how unclear requirements can create costly change once a project is underway. That's a scare tactic, though, and no substitute for creating a real partnership between IT and its business users. I'd be curious to know why the original poster's PMO seems so intent on avoiding that kind of give and take. Saving Changes...
David MorganProject Manager| Experian PLCGrantham, United Kingdom
I also believe a BA should be the person to write the requirements docs. If the company do not have a BA then they should either consider creating the role OR investing in training for their PMs to enable them to obtain the analysis skills required. Contrary to popular opinion, Business Analysis skills are very different from Project Management skills. Saving Changes...
Personally, I can't believe an organization that has a PMO doesn't also have the role of Business Systems Analyst. That seems like such a duh! moment to me.
Training your Project Manager's to fill the role of BSA is wrong as well. They won't have time to do a good job in either role.
If the company is concerned with how this would all work out, why not suggest hiring a contractor (make sure it's a senior analyst - yes, it's worth the extra money) for one project and comparing how much better it is to a project with no bsa or pm acting as bsa?
What about the difference between a Business Analyst and a Technical Analyst? We've got BA's that report into IT, but are more like Technical Analysts (i.e. they write Functional Specs that the Developers take to code). There is a Project Initiation document that's relatively high level and the business is "suppose" to fill out, but it's rather ineffective. We are interested in breaking out the BA and TA functions formally (taking the BA role out of IT), but not sure if this is going to be received very well by IT or the existing BA's for that matter. Anyone got a perspective? Saving Changes...
I think you need to differentiate between Project Management documents Project Plan, Quality Plan, Risk Management Plan/Strategy, Status Reports etc) and SDLC documents (Business Requirements – the problem, Functional Requirements – the solution from the user perspective, Technical Spec – the solution from a technical perspective, the code – the solution, acceptance Test plans etc). In an ideal world, the PMO should be responsible for writing the Project Management documents, a Business Analysts in concert with the business should write the Business Requirements, a Business Analyst in concert with the business and a technical lead should write the Functional spec, a Technical Lead in concert with the Business Analyst should write the Technical specs and Developers in concert with the Technical lead and the Business Analyst should write the code. I have been in IT for over 30 years and worked in all of the above roles. Only when everybody works together for the life of the project is there a truly successful outcome.
Ultimately the PMO usually has carriage of the Project (taking into account any governance bodies who have ultimate responsibility) and even though they shouldn’t write SDLC documents they should have a vested interest in seeing that they are done properly so that the resultant systems development (that they are managing) meets the business needs. But the PMO should always develop the Project Management documents as mentioned earlier.
Saving Changes...
