Human beings have been on this earth for 200,000 years and since the dawn of our humble beginnings from hunting and gathering, we have always loved to build things. This fascination has permeated every facet of our culture and has continued to advance over time. This is a story about how Project Management has evolved from 5000 years to what is now the ‘Digital Age’. Project Management is not some 20th or 21st Century recent phenomenon to organize projects. You can see the evidence of solid project management from the time of Egypt where the first pyramids were built. The Step Pyramid, the first of its kind was built at Saqqara, for King Zoser in 2750 B.C. This was a large-scale ‘technology’ project built by an architect and Chancellor to the Pharaoh, who held many titles like Builder and Director of Works of Upper and Lower Egypt. His name was Imhotep.
The Giza pyramid, known as one of The Seven Wonders of the Ancient World was built 150 years later (sometime between 2550 to 2490 B.C.) by Pharaoh Khufu, who was the second pharaoh of the Fourth Dynasty. One of the longest documented projects for that time period, spanning 20 years.
Many developments have obviously occurred since ancient times B.C. but one thing remains the same, we love building and creating tools to manage our progress and passions. In 1896, Karol Adamiecki, a Polish economist, engineer and management researcher created a system to visually track production and inter-dependencies. Then in 1910, an American mechanical engineer and management consultant by the name of Henry Laurence Gantt evolved the works of Adamiecki and created what is now known as the Gantt chart, which is widely used today to visually show the stage of a project’s tasks, dependencies, predecessors, resources, via a timeline.
In the 1950’s there were two significant introductions to modern project management methodologies, one was CPM (Critical Path Method) which was discovered in 1957 by Americans, M.R.Walker and J.E.Kelly. With the advent of the POLARIS project, a military operations deployed by the Navy (Lockheed Martin and Booz-Allen & Hamilton), in 1958 came along another method called PERT (Program Evaluation Review Technique). These are methodologies that helped to usher in the ‘how’ of planning, scheduling and controlling projects. 1967 was the birth of IPMA (International Project Management Association), which took concepts from the CPM methodology and created another variation called, Network Analysis, which was first introduced in two distinct conferences in 1964 and 1965 by founders Dick Vullinghs (Netherlands) and Roland Gutsch (Germany).
Across the Pacific, in 1953, the Kanban system was formally rolled out in Japan as a manufacturing and production tool. Originally used as a tool to help balance supply and demand, the Toyota company rolled out a way to keep production tied to a push and pull method. By forecasting the ‘push’ or demand, Toyota produced in a way that the ‘pull’ or production comes from the demand itself. This way they are restocking parts based on a push/pull method of their supplies needed on the factory floor level. The ‘driver’ of the demand is the customer or buyers of the cars. The goal was to use and re-up supplies efficiently without oversupplying the parts.
Then in 1969, two principle American founders by the name of Jim Snyder and Gordon Davis, formed PMI (Project Management Institute). Their goals were simple, to help foster project managers to share their knowledge-base and standardize that body of knowledge. The first ‘body of knowledge’ edition was created in 1983, which is known today as PMBOK (Project Management Body of Knowledge) and defined by PMI today as, “A standard is a document, established by consensus and approved by a recognized body, which provides for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context. Developed under a process based on the concepts of consensus, openness, due process, and balance, PMI standards provide guidelines for achieving specific project, program and portfolio management results.”
Most of these processes were given birth and focused around problem solving large scale engineering, military, manufacturing or production-based projects. The management of software or digital technology was not the catalyst of these processes. So let’s switch gears to the 1970’s and talk about the birth of Waterfall and Agile as applies to software development in the Digital Age.
Dr. Winston Royce wrote in 1970 a paper entitled, “Managing the Development of Large Software Systems,” which questioned and found fault with sequential development (or Waterfall method). The actual “Waterfall” terminology is first attributed to T.E. Bell and T.A. Thayer in their paper “Software Requirements: Are They Really a Problem?”, written in 1976 about using software development processes. As you can see by the Waterfall diagram software development still follows a sequential process very similar to a manufacturing or production process. The focus is on the requirements gathering, which is key before diving into design, implementation and so on. One cannot ‘initiate’ the next process till that predecessor has been closed. If you think about our modern concepts of time and how events can occur in parallel or out of sequence you can see why some people have problems with the Waterfall method. Because software development has impact around resources, end clients, changing technology, finishing one process before moving on to the next, it can have its own inherent risks. Let’s say you finish the Design stage but the client introduces a new requirement, you have to start from scratch again. Another issue is resources are sitting around waiting for one phase to be completed before initiating their phase. The pro of Waterfall is that it can be more thorough of an approach where you can discover defects easier when one phase is finished before going to the next. It’s also a very easy way to just jump right in if you are on a project to know what phase the project is in and constant client feedback is not so interwoven throughout each step.
With Dr. Royce’s concepts we can say that the birth of Agile thinking began as applies to software development, our Digital Age, and project management. Agile is not one methodology or process but a philosophy or way of thinking about how to execute a project. Agile is iterative or a way to revisit pieces or components of development over again called ‘sprints’ without defining it to such a level that it cannot be re-visited or enhanced again iteratively. There is flexibility and a more non-linear approach to gather requirements, build, test and deploy without waiting for one process to finish like Waterfall. There are processes that have sprung from this Agile thinking such as SCRUM, Lean Development, Kanban (used as part of an Agile framework), Extreme Programming just to name a few. A few downsides of Agile is if the requirements are not clear in the beginning, the client could receive something they really did not want or expect and that can cause long term business repercussions if not course-corrected. The lack of documentation (capture errors and apply learnings), but it also depends on the team, culture and how they aggregate their knowledge-base to share their learnings across the organization. The quick deliveries would require the end client to be very involved in the testing, sign-off of the product iterations and they may not have this kind of time or focused commitment available for longer projects.
In the Digital Age we are still learning and evolving. Personally, I don’t believe we are ever done evolving our digital processes and what works for one company may not work for another. Blanket adoption without consideration of risks and impact regardless can have devastating affects on resources, the bottom line as well as quality of execution. Agile is just one facet of the evolution of project management for our Digital Age. Organizations may not solely use Waterfall or Agile methodologies. They may use what is commonly known as a mixed-matrix, or adopt a whatever-works-best to get the job done philosophy. These inherent processes also have to be embedded into an organization’s culture and thinking as a whole. You can’t have traditional Waterfall business and then expect the team to be Agile without the infrastructures and tools to support their development. Balance is key and companies have to weigh out the risks and rewards in the long run by doing a thorough investigation. Also what works for a startup may not work for a more established company who has been implementing one process and wants to change to a new process. What may work with one customer/client may not work with another. Being flexible is key. In the end, common sense still needs to prevail (over promising and under delivering never works). Ultimately, a strong understanding of processes can help a business and their projects lead to more wins.
Author: Yume, Yume Consults