Author: Tom

How can we innovate if we stick to project management processes? Can we really plan innovation? How would it feel if a project manager created a Gantt chart with milestones that define when innovation has to be delivered? It sounds weird, doesn’t it?

According to Eric Ries’ Lean Startup philosophy. we don’t need a fully-fledged new product or service to test if the market actually wants it. All we need is to find a way to test if there is an appetite in the market, even if the product or service doesn’t exist already.

The first step, however, is to find out whether there is actually a problem that needs to be solved. Often, people fall in love with a problem (maybe because they already have the solution) but they don’t verify if the problem exists or if it actually needs to be solved. Maybe, users already have a solution for it that is good enough. If I look at all the fasting apps out there, I wonder why a decent timer of a mobile shouldn’t be sufficient 🙂 Usually, verifying the problem can be done by conducting interviews. However, beware of anecdotal evidence. This first step nevertheless already includes a multitude of work packages that a project manager should take care of.

The second step in an innovation project is to verify if the product or service to be built solves the problem. My favourite example is the first iMac. Apple removed the floppy disk drive from this groundbreaking new consumer computer, and almost everyone thought that this would be the end of Apple. The problem to be solved: Users wanted to exchange files but floppy disks only carried 1.44 MB (yes, there were Zip drives, but they were a proprietary solution). If Apple had asked users, they would have probably said that they need bigger floppy disks. But Apple included a modem so that files could be sent. And while customers were disappointed about the lack of floppy disks, today these disks have disappeared, and even huge files are exchanged over the web. Apple found a solution to a problem that was different to the one that customers had thought of but it worked.

How to test if a solution works depends on the problem. But it is obvious that project management will play a vital role here: We might have user tests, prototype builds, etc, all based on the results of the first phase.

The third step is about product market fit. Now that we know that the product or service solves a problem, we want to know if people actually want to pay for it and if we can reach more than just a few test users. Again, this will require the art of project management. How will we charge? What are the legal requirements? What about terms and conditions? There is so much to consider, so many lose ends that a project manager needs to connect.

Obviously, we don’t have a waterfall model here even if it looks like it at first sight. It is unlikely that we will be successful in each first iteration. We may need several iterations for the 1st step, again several iterations for the 2nd and so on and so on. All of these steps and iterations need to be documented. And there might be budget constraints, too.

To sum up, if you are asked to take over an innovation project, think of these steps. Even if innovation cannot be planned, these steps are a good framework to think about planning in an innovation context.

A few years ago, I wrote my first article about data science and project management. Since then, I have done several data science projects, mostly as the data scientist myself, but as it happens, as a data scientist, you cannot just spend your time building models. In fact, you will spend most of your time to understand the business requirements.

IBM’s Watson tv commercials have fueled the expectation that Artificial Intelligence is something that can easily be installed and applied to a huge variety of different problems, no matter what industry. In reality, though, not all Watson projects are successful. And this is not only a problem of IBM. AI projects or even Machine Learning projects as a subset of AI are a challenge to a lot of companies.

If we look at the PMBOK definition of a project, the notion of creating of something new is an essential part of a project. For traditional projects in other domains, often enough, clients, project managers and project team members already have some experience with respect to the industry. If you have built a house before, then it is easier for you to build the second house. The more houses you build, the easier it will get, even if these new houses have new requirements that you haven’t seen before. Also, clients do have a notion of what a house looks like because they have seen other houses. They also understand why some things take longer than others because they can relate to the physical world.

Data Science projects are different because clients usually don’t have any experience in this domain. And there are not too many experienced project teams or project managers that have done several projects in an industry to reproduce results for every possible question. A data science project will most likely not result in an application that automatically understands human speech and thinks like a human, just without the mistakes and a million times faster. But how can we manage our client’s expectations and at the same time understand what he really needs?

There is another difference: Houses are made of well-known materials. Data science projects usually rely on data, and often enough the data that is needed is not available and needs to be collected first or it is not available in the quantity or quality that is needed. Also, there is no proven way of making a data science project successful. In some cases, the results may not be as expected, be it due to the lack of sufficient data or that the algorithms simply cannot produce anything usable. Sometimes, we need to play around with the different data attributes (“features”) to understand which of them actually enable a machine to find usable patterns. We have been building houses for centuries now but only a few decades have been spent delivering AI or ML projects.

If understanding the business is the prerequisite for success, then it is of utmost importance that the business is committed to investing enough time for onboarding the project team and working with the team to collect the requirements and test early prototypes. If the goal is to increase productivity, then a data science project will mean decreased productivity during the project phase. This has to be made clear very early, and this may encounter resistance.

One of the best practices to ensure the success of a data science project is to define success very early in the project. The main question here is “When would you regard this project to be completed successfully?” Often, this question will be answered with KPIs that are not measurable. But that’s the point: If it is not measurable, then you cannot improve it. As a consequence, it is mandatory to go through this phase and come up with measurable KPIs.

KPIs, unfortunately, are not enough in most cases. A model can produce the best results in the world, but it is the business impact that plays a more important role than a model performance. A machine learning model can have the best performance in the world but may not have any business impact whatsoever.

Data science, as a consequence, is much more than just creating machine learning models. It is about creating business value by identifying the KPIs that really move the needle.

The pyramids. Built thousands of years ago. Huge buildings. In some cases, with very complex structures inside. How likely is it that these masterpieces were built without planning? Obviously, there must have been some planning to create the pyramids. Master builders were responsible for the completion of a pyramid, and a lot depended on being successful. Most probably their life. While we don’t know exactly how they planned, we can assume that they most likely did not call it project management, though. The notion of a “project” did not exist at that time.

The term “project” entered the English language with a different meaning than it carries today. In the beginning, a project was a plan, derived from a Greek word that meant “before the action”. Only later, a project was not only about “planning the work”, but also about “working the plan”.

Project Management as we know it today was formed in the 1950s. A few decades earlier, in the 1910a, the Gantt chart was invented by Henry Gantt. As a management consultant, he needed a system that would easily show what parts of a production are currently being built. Similar systems had been invented earlier, but Gantt’s charts showed dependencies whereas most other systems had not. Gantt Charts became augmented by the Critical Path Method, and project management was more and more regarded as a distinct discipline. The PERT technique followed a few years later.

In the 1950s, the American Association of Cost Engineers was built by early project managers, although they did not call themselves like that. This association did not only focus on costs but on the overall process of planning and scheduling. The first association with the term project management in its name came to birth in Vienna in 1965, the International Project Management Association. In 1969, the Project Management Institute was initiated in the US.

A project manager is asked to manage a project that is supposed to improve a software. He plays around with the software and also thinks that there is room for improvement but asks for data that supports the need to improve. He also wants to know what the business impact of an improvement would be. What are the KPIs, the Key Performance Indicators, that show that the project is successful? Unfortunately, the customer does not have any data whatsoever, there is just a “feeling” that something is wrong. Also, as he does not really know what is wrong, no business value can be attached to the project.

The project manager insists that a baseline is needed but the customer replies that he was not too happy about having a project manager involved in the first place since that conversation proves that project management increases complexity and adds unnecessary steps to the project. Sounds weird? No, that’s a true story. And I have experienced this more than once. And to be completely honest, I have experienced it on both sides of the fence: As a product manager, I was often annoyed by the additional questions asked by developers and project managers, and as a developer or project manager, I have seen product managers being annoyed when I asked those questions. In fact, starting a project without clearly defined goals and KPIs is like flying without a precise destination and without instruments that let you know where you are above the clouds. Continue reading