12

Caveat at the start - these functional titles may be interpreted differently in different organations Project Coordinator responsible for the adminstration/bookkeeping of a project: preparing budget breakdowns, frequential reporting, supporting standard meetings and Project Manager responsible for planning, managing and steering the day-to-day activities ...


10

TLDR They're a bunch of oxygen thieves who are holding you back. Either make them into useful people, get rid of them or have them guard the bees. Same point with more nuance (arguably): The BAs are essentially doing what would the job of the product owner and the customer should be doing. Potentially the preparation of stories is too much work for your ...


8

Here's my TL:DR answer: No! The engineer shouldn't be working on something if the business value isn't already defined. It's the voice of the customer (product manager, product owner, business analyst) that should be defining the business value. Said business value should be agreed to by the business before asking engineering to size the work for ...


6

Soliciting requirements is a iterative process, starting at an abstract level and diving down as you iterate. It is a data pull from the stakeholders; so it is about asking a ton of questions, several different ways, and becoming more tactical as you go along. Since it is a data pull, the techniques are not rocket science. It involves surveys, interviews, ...


6

The PMI view is: A Project Manager manages a project. They make sure they get done within constraints. He cares most about execution details in day-to-day work. A Program Manager has a bunch of projects. they may be a Project Manager on one or some of those too. A Portfolio Manager has a bunch of program. This is more of a strategic "where should our ...


5

Your Posted "Stories" Are Goals, Not User Stories As an Ecommerce Executive, I want to make improvements to the Request a Callback form which will make it easier to segment the callback request by purpose. This is not in any way a useful (or even meaningful) user story. While user stories shouldn't be detailed specifications, user stories that are ...


5

Your question appears to be looking for an answer that applies in all cases, all projects, all the time, or nearly so. If that was the intent behind your question, then my answer would be unequivocally no. Individuals can assume multiple roles and I would venture a guess that this is the case on most projects, especially those that are initiated under ...


5

As Zsolt mentioned, there's no other way to gathering requirements than getting in touch with the business. As you mentioned that you're a fresh graduated, you may still consider confuse the differences between Tech and Functional Specs. If that's the case, you can take a look at this article from Joel: Painless Functional Specifications - Part 1: Why ...


5

The easiest way is to organise a series of interviews with your clients. During the first session, you talk about the product, create some sketches either on paper or on the whiteboard about how the product should work (it may be a good idea to record the session with the permission of the clients). After that, you go back to the team, and together you ...


5

If you reduce or remove a non value adding activity the overall outcome won't change, but the process time will be reduced. Often the non value adding activities take some time, but they can be caused by unnecessary transportation, doing things again etc. In Lean production they are called waste. A couple of examples: corrections: when you have to fix ...


5

A metric would be a standard of measurement in the context of PM. A performance indicator on the other hand is also just a type of performance measurement. Both terms could be and are used synonymously, e.g. here. The K in KPI would be the difference if any. One would consider the Key performance indicators the most important metrics that provide the best ...


5

Leadership 101: Do not force the team to do something for the sake of doing something. On the surface, it seems to be a very nice idea, being poorly implemented. The straight answer for the question is no - it does NOT make sense to force engineers (coding-oriented people, who usually have collosal knowledge on programming but low communication skills) to ...


5

A title is just a name. One of the first jobs I applied for just out of university was a position called "Superstar Programmer". Another was "Junior Programmer". Had I taken the first job, would I suddenly be a better programmer than had I taken the second? No. Of course not. You know what the job title was of the best Project Manager with whom I've ever ...


5

They're just different roles. A PM is responsible for guiding the project to successful completion. A Business Analyst is typically responsible for elaborating the solution from concept to detailed requirements. There can be conflict between the two roles, also. In some organizations, there is a combined PM/BA role. I tend to recommend against them, ...


4

At the initial scoping phase of the project you need to understand what the client wants and what users want. Your project management skills will be tested in trying to balance both sets of requirements and deliver a product both are happy with. To understand your client's requirements use the techniques that other answers have proposed including what you'...


4

I'm not sure we've answered the OP's question: How do you prevent a situation where you have to produce work-product work first and get client feedback before getting on the right track to meet their needs? If I understand the problem correctly, the OP is working with the client to develop the initial requirements for the project (pre-initiation). The ...


4

TL;DR There is no "best" answer. Project management involves a lot of soft skills and can be very situational. However, there are some clear delineations between roles, and rules of thumb for optimizing teams. Different Roles Should Be Separate A project manager's role, when done properly, is a full-time job. So is business analysis. That doesn't mean ...


4

Your data gathering is insufficient to arrive at any conclusions. If you only interviewed the original middle manager, and then other managers, you have missed many other data sources. You need to interview other employees; higher level managers; conduct focus groups and surveys; observe the work in progress; review company documents suchs as various ...


4

I once read a case about a development organization - they were trying to improve the administration of justice in an underdeveloped country. They had a way to measure the administration of justice (IIRC, the % of decisions that were overturned on appeal or review). But they had no way to influence the actual decision. Root cause analysis indicated that ...


4

this is the job of the engineer working on the issue as they're the one most familiar with it. Technically, no. The engineer working on the issue is the one most familiar with the technical details of said issue. The one most familiar with the issue itself would be a Business Analyst (BA). Furthermore, engineers often have different priorities. I would not ...


4

Your biggest problem is a toxic work environment. As you note, we yell at the technical person telling him almost literally that he is "not smart" enough to understand what we are trying to do. If someone were to do that to me, I'd immediately demand an apology. If I didn't get one, it'd clearly be time to update my resume... or perhaps even go to HR ...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


4

Ignoring the substantive issue you're facing and focusing on the process of problem resolution, the general flow looks something like this: Clearly articulated problem statement: seems like you have that; Identification and analysis of potential root cause(s): seems like you have this, too; Analysis of Alternatives (various business model possibilities): ...


3

This is still a very complex question, and I think it is possible that an answer will nail a part of it and miss the whole. I'm still thinking about the problem, but in the interim, I found the following quote today The design specification must be governed differently than the requirements. If the requirements were appropriately governed, and if the ...


3

So if I understand right, your company thinks you should build an application for your customer. The customer hasn't requested it and you have no validation that the problem being solved even exists? How you proceed is really going to depend on where you fit in the overall organization. I'm going to assume you're a program/ project manager (given what this ...


3

Calling the top-management sounds pretty much like ignoring someone in the hierachy. If the PM is able to come up with functional requirements he has at least some business problems or market chances in mind - even if the PM is not able to formulate them, e.g. The customer would like to use a fancy tool in oder to "feel" cool. The company has to create a ...


3

TL;DR; How much analysis is needed: enough analysis to enable the team to implement the user story. In most of the cases this means all information is available and there are no open questions. This should be done iteratively: the closer the implementation-sprint the more details are added. I personally think it is a good thing that you have the intendend ...


3

"So, what is the best way to collect business requirements?" As others have said, working directly with business, managers and staff (SMEs), is the best way. Given that, you can't just ask what they want; that is an open-ended question. Creating a prototype is a good way to give feedback on the requirements, but it is much better if you have a grasp of the ...


3

What are you doing to make sure you get the requirements that you want? I practiced as a BA for several years at a large company. I will tell you that this is not an uncommon problem that you are having. I can also tell you that the only way It gets fixed is when you and the BA get on the same page. Yes, the BA is supposed to document the requirements in ...


3

Whether you're doing a big or a small project your approach should be something like this: Discover what the users want (go talk to them, for example) Build a smallest version of that (for example no user management, only with dummy data etc.) and ask for their opinion If they liked it, start working on improving the functionality (add whatever you need to ...


Only top voted, non community-wiki answers of a minimum length are eligible