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 ...


8

To answer this effectively, it is important to split roles, job titles, and skills. Scrum has absolutely nothing to say about job titles, so we can actually resolve that fairly quickly by saying: as long as a particular "job" does not expressly conflict with Scrum, it is "allowed" in the Scrum framework.That isn't to say that particular ...


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

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

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

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, ...


5

Assuming that you are the Project Manager (otherwise, why would you post this to our site), you have no "right" to disclose this information to your team, since it was told to you in confidence. Your task as PjM is to ensure the project will be in a deliverable state by the "firing deadline" and that everything is well enough documented ...


5

TL;DR The canonically-correct solution is to put someone with business analysis skills onto the Scrum Team in a Developer role, and then cross-train the whole Scrum Team. Cross-pollination of skills enhances the capabilities of the Scrum Team and the Developers, and builds T-shaped people. Including someone skilled in business analysis on the Scrum Team also ...


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

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

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

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

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): ...


4

I usually see BAs work in one of two ways. Sometimes they assist on items being developed in the current sprint by providing their domain expertise to developers, helping to fill in any missing details and working with users and testers to understand any problems. Requirements don't have to be fully defined at the time of sprint planning - they just need to ...


4

There are two answers here - the Scrum answer and the my practical answer. In Scrum, there are three "accountabilities" (prior to the November 2020 revision, roles) on a Scrum Team - Scrum Master, Product Owner, and Developer. A team has one Scrum Master, one Product Owner, and everyone fits into one of these buckets. However, if there are multiple ...


4

I have seen many business analysts work well in Scrum teams. The three biggest challenges for them are typically: Reaching a clear understanding of roles and responsibilities with the Product Owner Adjusting to the just-in-time nature of Scrum - looking to add detail at the latest possible moment Becoming good at responding to change - taking feedback from ...


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

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

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 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

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