Personal project methodology
-
Share:
-
-
-
Before we start our discussion there is a very interesting report "Chaos Report"(for 2013) from the famous company The Standish Group on the status of project management. It contains a list of factors that lead to the success of a project as well as a detailed analysis of each one. I recommend that you take the time to read it because it is very useful. The reality is that in my 10 years of experience in project management I have never used a methodology in its classic form, and by this I mean the way you find it in a book. I suspect that most other project managers out there do the same. There are always certain circumstances that force us to, for example, build a Scrumbot from Scrum. Let’s not even mention more complex methodologies. Waterfall in its pure form is rarely applied in software development. You occasionally identify it in writing, but in reality, it is anything but Waterfall.
I will tell you a story. I once led a group of projects where we had established with the customer that we would be working for a fixed price and we would be using Waterfall. The problem was that we had to implement Waterfall for every release which in turn lasted for about 4 to 6 months. In practice, the fixed price could be implemented while at the same time ensuring the project’s profitability. However Waterfall was impossible to do. The system was very complex, large and old and was connected with another 30 systems so that changes usually appeared on a weekly basis. We couldn’t freeze the scope of the project, not even for a month let alone 6 months. On the other hand a more flexible approach wouldn’t have worked. The responsibility for correcting and stabilizing the system was huge. Plus the volume of the code and modules inside the system meant that we couldn’t avoid a chaotic work process and a maximum level of documentation.
What can we do? How do we manage projects that, because of their volume, complexity and consequences of downtime require Waterfall but who also require Scrum, due to the constant changes.
Selecting a personal methodology for each project
Carefully analyzing the majority of methodologies (from less agile to more agile) I came to the conclusion that any methodology uses absolutely all areas of knowledge related to project management. By areas of knowledge I understand the following items on the list (the list might not be complete, but it does not change the essence of this article):
- Change Management
- Communication Management
- Requirement Management
- Configuration Management
- Risk Management
- Project Initiation
- Project Planning
- Project Execution
- Project Monitoring and Control
- Project Closure
- Product Design
- Product Implementation
- Product Documenting
- Product Integration
- Product Releasing
- Product Review
- Product Testing
All of them in one form or another (this is important) are present in any project related to software development. The only difference is how much they are used – their "weight" in the project so to speak. The volume and quality of these areas of knowledge is what I call "the weight field of knowledge." Thus, we can safely say that in absolutely any project we use all the areas of knowledge management involving projects and products. The only difference is their "weight".
As a result we introduce the concept of "weight" or grading - from Grade 1 to Grade 4, where Grade 4 is the most "heavy" grade. Thus Grade 4 would be a methodology such as Waterfall and RUP and Grade 1 would represent Scrum, XP or the Kanban methodology. The magic begins when we try to describe the grades in the middle – grade 2 and 3. Of course, it may be that some field of knowledge in your project is not represented in any way (for example, risk management). In this case, this area of knowledge will have a grade of 0.
In the second part of this article we will look at the benefits of this particular approach.
Alex Egoshin
Project Management and communication specialist