Project Management and Governance

What is a successful project?

There are several answers to that question. In theory, a successful project is one that delivers on time, with the right quality at the budgeted cost. The classic TQK classification (time, quality, cost) should stipulate what is most important. Whether it is done with that method or if you as the client do this in another way is not essential, but that it is really done - that's essential. If you ask a controller if a project is successful where the delivery was above expectations but at a higher cost, you will probably get a different answer than if you ask the users of the change. And vice versa.

The most important definition is to deliver what needs to be delivered! In that process, you as a leader must be transparent, both towards "your" client and those who participate in the activity. The task as a leader is to create this understanding for all stakeholders throughout the life of the project.

Why different methods - agile vs traditional?

The Agile Manifesto does not contradict traditional management and governance. Being quick-footed and able to adapt development in projects to a new reality (requirements) must be possible - regardless of method. There is really no contradiction in this.

In many organizations, you work Lean/Agilt and maybe even in business teams that are fully responsible for their product. However, it is not unusual for there to be a "legacy" that must be taken into account, it is more the rule than the exception. It could be organizational legacies, such as the fact that you need to belong to a certain department to get authorizations in certain environments, or that there are delivery and decision routines from previous processes that have not been phased out, or adapted to the new way of working.

The point is that you must have a good ability to adapt agile working methods with existing methods and processes. This is something we have worked on a lot.

How a migration is carried out?

A migration can of course be carried out in several different ways. However, an important principle has emerged, is to approach a "1:1 movement". That is, avoid making improvements during the migration itself, even though it may be appealing "while you're at it.". This can be a big risk to both schedule and budget. If changes are to be implemented, these changes should only take place after strict change management, and in most cases be done on the existing platform and then migrated. This especially applies to bugs found in migrated code, i.e. bugs that already exist and have been discovered when testing on the new platform. This in particular may be something that the client and project management need to fully agree on at start-up. It is often said that the existing platform was never as good as when you leave it.

A migration project is mainly a test and infrastructure activity, besides the actual migration. Although there are additional parts to the project. But the principle and organization of a migration is pretty much a given if you have done it a few times. The question of whether you can work agile in a migration project often arises, the answer is that it is possible to find agile principles in the working method, but that the requirements should be fixed and that 1:1 should apply. There are great risks in doing otherwise. That is, during a migration there needs to be a mix of agile working methods and traditional working methods.

There are also different theories about the deployment process, a "Big Bang approach" or rolling out smaller parts. What's right and what's wrong depends entirely on the type of migration you are working with. goLive has experience with both methods.

How is a transition carried out?

Unlike a migration, a transition is a move of existing equipment to another site. For example, if you change infrastructure from your own ownership to a sourcing strategy. In that case, the project will have to handle requirements and agreements in a different way than in the case of a migration. The project should be controlled jointly, but the recipient (new supplier) is the one responsible for the implementation. As a customer, you must have an organization for testing and verification, as well as be experienced at follow-up. Both regarding progress, and on agreements.

During a transition, it is very important to set the structure of the assignment together with the new supplier. It can be about timetables and practical implementation, contracts and budgets as well as finding the form for different forums, for example a joint steering group.