5

One project, multiple epics I don't really see how 25+ epics will be more chaotic than 25+ projects. Don't overthink things. Redeveloping a monolith application into a micro-services architecture will be challenging enough for your team, they shouldn't also be forced to analyze things from an organizational point of view to see where each task goes where. ...


4

You don't try to handle everything up front or predict the future. It's a waste of time and effort. As you build out the software and get stakeholder feedback, you will learn more about the true needs of the stakeholders. I'd recommend looking at the techniques of Agile Data and Agile Modeling. These two sets of practices can help you apply and integrate ...


2

You don't. Schema can be changed at any point in future. Predicting perfect schema is impossible. I say that after doing this for 6 years now. It is simply impossible to know what can come up. With that said, you should definitely consider normalisation, adding basic security measures like using guid instead of sequential numbering, option to ensure ...


1

I don't think there's a right or wrong answer to this question, but here are the main factors I would consider: How many teams will share the work? If you have more than one team (especially if they might end up using different types of workflows), it might make sense to create different projects. How distinct will the modules be? Are there some general ...


1

One thing I have found that really helps with engaging busy users is to schedule them in way in advance. For example, I might ask them to make a 2-hour slot available every fortnight. This would be a recurring event in their calendar, so there is no reason why they should be unavailable. Discuss with the users what time slot best suits them (day of the week ...


1

Strongly normalized data schema should be more flexible to change to meet evolving requirements. Ensure the schema is normalized. Beyond that, this is a quality/suitability to business requirements problem. Collect and test against your requirements. Rely on your team (although I think the most important phrase in your question is that you are the only one ...


1

Firstly, I'm not so sure this has to do with Project Management. More to the point, why bother? It's rather simple to add fields to a database - even a live one. If you're really paranoid, you could always add a few extra fields, to be named spare1, spare2, etc. and use those later. To answer the actual question of how to ensure that there is nothing left ...


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