Project management has contributed diverse triangles as it has evolved. From the traditional project triangle to the agile inverted triangle and, recently, the agile triangle. In this article, I am proposing going one step beyond the agile triangle by taking into consideration lean thinking to add a fourth element, specifically that of design, to form the lean-agile prism.
During my last business trip an upscale long-stay business hotel asked me to make an assessment of the operations automation software system they developed in- house. One of the objectives of the hotel is to differentiate from competitors by offering its guests amazing accommodations and very efficient service. Its rooms are fabulous, with great interior design and functionality. Customer service seems to be good as far as I could tell (best way to assess that would be by staying as a guest for several days). An important factor they have been working on to offer excellent service is a high-degree of automation. To achieve that they have developed most of their software systems in-house and wired the entire building such that they can monitor and control all sorts of activity. It goes from familiar functions such as room access monitoring to access to safe boxes, detailed phone activity, Internet usage, room cleaning service, laundry, parking, lost-and-found, promotions, you name it.
The amount of work and time put into developing all of the automation systems and the level of automation achieved is impressive. As the systems manager (Let’s call him Mike in this article) proudly showed his amazing work —and I really mean his work since Mike single-handedly developed pretty much all the software— I noticed that he also expressed frustration because the hotel staff continuously called him for help. The pager would go off at any time of the day or the night. The staff would have all sorts of problems on issues that didn’t really exist because the software actually covered them. The high incidence of human error was also very frustrating to Mike. He was sure the problem resided in the level of education and the lack of familiarity with computers of most of the staff.
What are the real issues? Let’s analyze this from the project management triangles standpoint.
II. Analyzing Triangles
The iron triangle.
Quite some time ago I started taking project management courses. At one of those courses, the instructor started talking about the iron triangle . It depicts the three main considerations for project management: Scope, Cost, and Schedule (see Figure 1). This tells us that we must determine, measure, and monitor those three if we want our projects to be successful. Conceptually you must determine the weight of two of them and allow the third one to slide as needed to accommodate those weights. Traditional projects are plan driven, save rare exceptions, and that means cost and schedule estimates drive the restrictions, which are the features.
Since my focus of attention at that time was on quality assurance I raised my hand and asked the instructor: “excuse me, where is quality?”. He made a pause and then said, “quality is implicit and in the middle of the triangle”. I wasn’t pleased with the answer because I think quality is too important to be just “implicit”. After that day I didn’t go back to finish the course.
Figure 1. The Project Management Iron Triangle
In real life, there are executives who set all three of the triangle’s considerations at the beginning of the project and don’t change them until late in the game, when the actual circumstances give them no option. Upper management tries to avoid such fluctuations because it is often considered a sign of failure, and as consequence quality is compromised too often.
Although Mike has a 2-person staff that is under-qualified, he is still a one-man show who is so busy attending all sorts of matters that the time to enhance and maintain the current code base becomes extremely