How do you organize your system development projects?

Any system developing as per business requirement, priortizing and mantaining future requirments, searchable, configuraable implemention, easy adoption for both UI and business backend development requires well organized understandable and managable softwars which follows agile methodology would be great fit but often seen smaller projects easy to maintian using agile while complex and big projects, their MVP itself so vast maintaining only agile is not just right fit. I would recomand a hybrid approach which would marriging between water fall with agile methodology would be ideal fit.

Make an informed decision when choosing an appropriate methodology. One that supports the organisation and the organisation can get along this methodology. If there is an environment to support agile methodologies then and only then go for it but if the organisational need is a complex and complete system in a single go then waterfall is the way to go. Mind the surroundings and muddle through in the right direction.

In the crazy days we are living today, agile is the best strategy. Agile means starting with the simplest solution, keep improving and adapting on the way, be ready for things to change dramatically and make sure to get user feedback as soon as possible 😉

It's important to remember that the methodology is there to help you achieve project delivery goals. It is Ok to be flexible and tailor the process to fit your project needs, team dynamics and organizational culture. For example if you are using a waterfall approach adding prototyping with feedback loops can provide great value. If you are using an agile approach you can augment documentation requirements or tighten the change management process to avoid some of the common pitfalls.

This may seem trite to many of you but it is based on 60 years of experience across four companies and accompanied by a lot of scars. The single most important factor to project success is to have the right people for the job. If you have the right people, they will fix what is wrong. If you don't have the right people, there are no methodologies (or tools or processes or ...) that will save you.

Make sure that you have defined your User Needs and Intended Use (UNIU) before jumping into the System requirements and so on. Tracing your requirements to the UNIU is the key to ensure if there are any orphan requirements 1) You have an UNIU requirement, but you don't have requirements at the system to map them against 2) You have system requirement, but you don't have a UNIU to map it against. Both scenarios needs to be looked into with detail. These scenarios will result in an overkill or underkill conditions.

Requirement reviews and validation with various stakeholders is very important. As you know issues and defects cost less to fix earlier in the development process. So identifying a missing or incorrect requirement early will safe a lot of effort of later rework when it becomes much more costly.

If it's possible, get everyone involved in the project in a room ( or a virtual room 😁) and start discussing the project. The goal is to align on - what is the problem we are trying to solve? - who will be involved/ affected? - what is the simplest way to get started?

I agree, but this activity should be a quick and thorough. Thorough means develop user stories, do the necessary job shadowing, run all the techniques to gather all aspects of requirements gathering and then analyse and document them properly. Quick means there is a certain drive to do a project either by senior management or an intrinsic requirement for change. The project should be within the boundaries of that drive or the drive should be reinforced from time to time till the completion of the project.

A requirements baseline is fundamental to success. It should also be a part of a set that includes budget, schedule, risk and (system) performance baselines. Logically, a requirements control (change control) process/board is needed.

In my experience, the System Architecture is a must. It should be designed early and should cover all components and breadth of the project. There should be questions about the detailed depth of a component but these questions should enhance the depth of the design but later identification of nee integrations may kill the purpose of having a complete system architecture.

Some System Architects (including me) maintain a distinction between the architecture and the design. The architecture does not specify a product whereas the design does. For example, the architecture requires a data base or a messaging tool or a transaction processor and the design would put in a specific product. This allows for various products that could satisfy the architecture.

Overall architecture is important, but granular details need to be owned by each technical team. In my experience the best way to do this would be for the architect/s to collaborate technical team leads to agree "how" the various systems will work and their respective integrations, (as an example this is there contract first patterns can/should come in).

Desing some very high level architecture. Don't try to figure out all the details at this point. Question marks should be all over the place at this point and that is ok.

At this stage, architect act like God or the creator of the system, should be focus on master plan while is aware of many details and is leading them in their best direction. The mindset of seeing the jungle and also a tree, at the same time, is one valuable asset for this job. You should be able to control big picture and many detailed picture, both. In my experience, it would not be an easy job. But the result may be satisfying. Welcome to the sweet world of conflicts!

Before choosing new tools, make sure to verify what tools you are already using to tackle these problems. Consistency is more important for a tech team than beeing up to date with the trends.

The selection of tools and development pipeline should be defined as a organization wide guideline. One of the few times this would be re-evaluated would be if a project requires something so specific that it has not been considered previously. If this is case then this decision needs to bubbled up to the greater strategy regarding tooling and development pipelines

Implement the MVP or a POC. Start as small as posible. Publish it live. Start getting real user feedback before moving to the next atep of implementation.

There should be an overall guiding principles to what "good" looks like in terms of coding standards. These principles will act as a north star for various technologies, but each technology may have limitations as such these cannot be immovable. Should there be a limitation that prevents guidelines from being followed, this needs to be highlighted to the greater team. The reason for this is that other technology areas should be aware of the possible limitations that could have an impact on their deliverables or there may be solutions in other areas that could help mitigate not being able to follow the guiding principles.

Please document the logic before implementing the code. You spent all that time designing the architecture, you need to spend time documenting the logic you're going to implement too. Implementing the code is not the next step here. Engineering the logic to be coded is. Why is everyone so determined to code first ask questions later? Create a flowchart, an ER diagram, a sequence diagram, then code it.

With majority of the industries being regulated these days, its key to have a clear defined regulatory strategy in place from the beginning. Without a clear understanding of the regulatory pathway, your deployment is prone to failure. There are some regulatory bodies that takes significant time for review. We need to ensure that this timeline is accounted for in our planning.

Early feedback and continuous improvement : The seventh step in organising your system development projects is to continuous review your system, collect the feedback from the stakeholders and improvement.