Introduction
I've been around a bit. Spent time in several companies, seen projects fail and succeed. Each time, the company used some different methodology to get projects done. The truth, the WoW (Way of Working), is proven to work.
Or is it?
This article is meant to be lightweight.
Background
I tend to, it's in my character I guess, to simplify things. I love the KISS principle (https://en.wikipedia.org/wiki/KISS_principle) and certainly dislike complex explanations, especially if they are not built up very well.
Often the company you work for uses a WoW (Way of Working) that customers are not familiar with and you end up in a meeting with nice slides that should explain this. Customers nod in agreement that they fully understand everything (their ego in the way of admitting they do not fully understand the consequences) and when it comes to actually executing the work, things fail ... over and over again. Equally often, because your own company employees don't have a clue...
Methodologies
There are numerous methodologies out there. They are not all bad, this article is in no way intended to be critical towards any methodology or framework. Let's sum up a few:
And some of those can be used in hybrid modes, e.g., agile frameworks in DSDM, or in the V-Model.
When you read up on those, I always noticed that they promise timely delivery, in scope and in budget. Of course, you need to promise those three things (sometimes quality is added as well) as they make up the Project Management triangle (https://en.wikipedia.org/wiki/Project_management_triangle).
Quote:
Don't blindly copy any methodology. Read it, learn it and tailor it, to your company needs, making sure that everyone is on board with the concepts.
Too many times you see managers coming into a new company, hired to fix the companies problems and the first thing they do is take the WoW (Way of Working) of their previous job and slap it as a solution onto the company. If it doesn't work out, you get sentences like "We need to educate the customer", "people are not with me yet", "You don't understand what we're doing", ...
If there is one thing I learned from these situations: You cannot project a WoW (Way of Working) blindly from one situation to another. The only certain outcome will be: "It does not work".
Which doesn't mean you can't transfer the know-how, or the principles. It does mean: tailor the know-how to the new situation, because as similar as it might look, the situation will be different: company size, company culture, the projects/products you build, the customers and their sizes and cultures or even the number of customers, ... and so on and so forth.
Quote:
Don't slap a WoW (Way of Working) as a viable solution from one situation to another.
That also counts in your private life for that matter.
What to Watch Out For
Every process, in its entirety needs to adhere to, what I call the "three boxes".
The Three Boxes
| Analysis | Development | QA |
Looks simple, is simple and you might even have a "palm meets face" moment, however, you would be surprised how much fails just because of this. Of course, the three boxes are just a starting point. It's where you draw in your employees and your customers. It is a fairly safe assumption that anyone can understand this. (although don't quote me on that).
From here, you can start explaining any WoW (Way of Working), any methodology you like, because you can overlay these three boxes on top of any (more detailed) WoW (Way of Working). You can add phases in front (pre-sales, sales, ...) or at the end (delivery, aftercare, maintenance,...). If you can't, there's, or there will be, an issue.
The three boxes are the fundament, the basis for each project management/software development. From there, you can drill deeper.
You can also split the boxes if necessary: functional design, technical design, high level, low level or several layers of QA process like technical tests, functional tests, customer acceptance tests, ...
By no means should you have "only" three boxes or three phases in your development process. However, if you check all your phases you do have, you should be able to fill in the three boxes and no, this is not always the case ...
or it is not always done correctly.
- incorrect order: e.g., you start developing while the analysis is not done yet, or done after the facts.
- QA is one step performed at the end of the process: not so, QA is part of the entire process starting with analysis or even before that.
- Usually, unless there is a very good reason, the time for each box is 1/3 of the total time.
If development takes 2 weeks, so does analysis and so does QA.
If development takes 6 months, so does analysis and so does QA. - ...
Not to be underestimated, you can use this as well to synchronize a WoW (Way of Working) from a customers methodology with your own. If your customer uses DSDM and you use Prince2, use the "Three boxes" to sync up the phases of each.
So in the end, it boils down to a simple statement:
Quote:
The "Three Boxes" are a means for communication.
"Communication" - Probably the single most important aspect of project management.
Points of Interest
This concept is very difficult to get across. The reason for this, and this might be my personal opinion, is that it even might be too simple. People feel threatened because they feel treated like they are "dumb", yet so many times, I see those same people skip phases, rush work or not adjust their methodologies and run straight into walls, head on. I guess it can be remedied by educating customers or having people "get" where you're going...
