Projects like to be managed. We should have a strategy so as to be sure that our activities will end successfully. Obviously, sometimes are were projects that left to fend by themselves and then closed, but the final result of the majority of them was not as expected. Frequently, communication noise occurs in such cases and leads to many mistakes, extension of completion time and other problems. Therefore, multiple different methodologies of project implementations have been introduced, facilitating task delegation, allowing to foresee mistakes and analyse data.
Methods of project management – instructions, but no specific formulas
Even if we do not use any project management methodology, we have to remember that every project is to consist of three elements: budget, action plan (e.g. milestones), and specification. The budget obviously equals to the resources that we have to perform the undertaking, the action plan is a specific roadmap that is to lead us form the commencement of work to its very end. Those two elements are of no use without specifications, i.e. description of the final effect, and the method of its accomplishment.
This can be easily explained based on an example. Let us assume that we want to develop a phone application. We know that it is to allow ordering products home on days when shops are closed. It has to be supported by phones and tablets, and it must be easy to use. These sentences are not the specifications, it is just a very general outline of the idea. The specifications do not have to be a book full of technical nomenclature, and diagrams but is should contain a number of functions important for us and the recipient. Its development is often preceded by surveys, research and interviews. We have to check in some way what the market expects, and how we can meet those expectations. A very good example is the 5 days’ sprint method we posted some time ago on the blog. In this case, these 5 days are the time we need to start from an idea, go through its realisation and reach the test phase. For the first stage of a project, this seems like a great solution.
Returning the methodology itself, it has to be remembered that they are more of a guideline than a formula for success. This can be shown perfectly on the basis of statistics provided, by instance, by McKinsey & Company – according to them, 17% of IT projects go so poorly that they threaten the existence of the company. Up to 70% of projects is never implemented at all, and only 2.5% are completed in 100% (data from the Gallup research). 57% of responding project managers claims that an online tool for project management was used where all information, remarks and changes were specified. Why did they decide to do so? All this due to communication noise that 7 out of 10 employees complain about. Any management tool, or even Google Docs or an Excel spreadsheet that the engaged employees have access to, will facilitate work of the entire team.
Agile, Waterfall, or maybe MoScoW?
Let us start with Agile and from the fact that is not really a methodology, but a specific way of work described 16 years ago. For more information on Agile, click here. Agile is divided into several types and the actual selection of the adequate model depends on the size of the enterprise, level of project complexity or many other factors. What makes project management using Agile different is that it is simple and flexible, concurrently observing the principles of other methodologies, e.g. LEAN. It is said to be one of the most popular management methods that works well for a fixed budget and deadline. It should be added that it is referred to as the agile approach to management. The mentioned sprints are a type of this operation method.
Waterfall is a completely different approach – it is a cascade model which, thanks to its repeatability, provides great, and sometimes full foreseeability of what will happen in the course of the project. We need a vision of what we expect. This allows to create an exact plan, a delivery schedule, and – thus – determination of a specific completion date. This also gives us the information about the exact project cost. This methodology proves itself in management of high risk activities, where analysis and tests are always in demand. This happens, for instance, in the banking, insurance and health care sectors. Let us imagine we release an application to our customers before it is thoroughly tested and they could lose money while using it. The disadvantage of this methodology type is the fact that the effects are visible very late and introduction of changes is troublesome.
MoScoW is also the methodology of management, based on activity prioritisation. The main goal is reaching an agreement as regards meaning of the particular project elements. MSCW comes from the first letters of words: must, should, could, won’t. When running a project, we choose the elements that most important to us and which have to be performed. Two are elements are postponed. The third group regards the components that “would be great”, and the fourth segment is neglected from the very beginning. This way, the team is focused only on the most important aspect of the project. This strategy works great for IT projects.
What to choose?
As we have already mentioned, there is no formula for success, but analysing various project implementation methods and their adjustment to your actions is worth a while. Another very important factor is on-going analysis and control. However, the most important thing is to stick to the action plan, but not at all costs. If, at any stage, it turns out that there is another option that will be more effective and will not affect the entire process – why not use it?