PM software as a sales argument - part 2

In the previous post, Can Do developer and CEO Thomas Schlereth looked at the promising effects of professional project management on the bidding process and on sales presentations by service providers. This time, he looks at why PM hasn't been playing its rightful role in sales for a long time. In addition, he tells from practice what can happen when good PM does not receive attention in the company.

Why are offers not always presented with a professional project plan?

As a manufacturer of project and resource management software, it is natural for Can Do to do just that. After all, if we can't do top-notch project management, using our own software of course, who can? But why is this not presented in the same way in many other areas?

The simple and quick answer is obvious: The providers simply can't do it!

The companies are completely focused on their technical competence and want to convince exclusively with it. Little attention is paid to the actual project management.

Perhaps there is another reason, but it is not an unfounded insinuation:

All project planning elements in a sales presentation, as I presented them in the previous post, contain one essential point: they represent a commitment. A commitment to dates, capacities, and processes, binding agreements - albeit vague in parts - that offer little room for deviation or excuses. It is a commitment based on the certainty of one's own competence and experience. With good providers, this should not be a problem either.

Is the competent presentation of the project the game changer?

No, that is certainly not the case. The professional qualification and the trust in the persons of the provider, his references and the presentable thematic successes weigh much heavier. But three or four slides in the presentation and also as part of the offer can simply bring plus points in terms of trust and thus be decisive.

That shows the future customer that the provider is not only technically good. The other offerers are naturally also not bad, otherwise they would not be allowed to present their offer before such a committee. It shows that the provider really takes the customer seriously and really wants joint success. It creates trust as partners and the basis for goal-oriented cooperation.

Bloopers

After more than 20 years in this environment, in all roles, as vendor, customer, consultant and decision maker employed by companies, one naturally experiences amusing and sometimes even shocking moments. Of course, I cannot name companies, projects or even people here. Therefore I paraphrase the examples.

1. As a steering committee member for a project in one of Germany's federal states, I was asked to make decisions about funding projects in the area of digitization. Municipalities and communities were applying for substantial funding to drive digitization forward. One project application was justified by the fact that the municipality was broke, owned a plot of land for the project, and the local contractor was currently experiencing a slump in orders. To evaluate the project process, I asked for a timeline (project planning) and a description, albeit brief, of the project's success. Handwritten follow-up was that the contractor would then get another contract. That would be the project benefit. The project period depends on when the contractor has staff for it (resource planning) and always assigns staff when his people have nothing else to work on. My interjection that the project will never get done if the contractor gets a lot of orders from other builders now was presented: If that's the case, we don't need the whole project. I did not recommend approval of the project. 

2. In an approval committee, in which the board of a company asked me to give an assessment of upcoming IT projects, a project was presented that would cost several million. Although the company had good project software (Can Do), the planning was presented in a PowerPoint slide. During a break in the meeting, I advised the board to consider the project, but to bring it forward 2 months. The director presenting the project was asked to drag n drop his entire plan quickly in PowerPoint after all, and then make a statement as to whether it could be done. This was not possible for him. The decision was postponed, the plan was transferred into the software and presented again. The result was that the project could not be realized at all with the existing capacities. It was rejected. This may have prevented damage amounting to millions of euros.

3. At a company whose project and capacity planning was far removed from reality, we were asked to check the feasibility with our solution. In technical discussions it turned out that the company had been searching unsuccessfully for 8 years for a professional solution available on the market. These - quite simple - IT projects as well as their conditions and processes were so unique worldwide that simply no one could map them with software.

It only works with an Excel file created by the decision maker himself. Our comment that these are normal IT projects that can be mapped by virtually any computer program was eloquently dismissed with unbelievable detail problems. The decision maker simply wanted to keep his Excel file and with it the sovereignty over the data and information. The management was technically unable to recognize the situation. Therefore, we withdrew from the project at a very early stage.

4. In one project we were confronted with a company that had lost all overview of projects and resources used. The situation of the whole company became critical as a lot of money was burned. A quick solution was needed, and we suggested to simply store all projects with their names and start and end with the generic resources in the software to get an overview.

In doing so, the software discovered that two thematically identical projects were running in parallel at the same location. Significant resource conflicts were found. Employees were working simultaneously on two different software projects with the same project assignment. The projects were released almost simultaneously by different committees in two business units. However, since the specialists for the two projects were the same people, they were working twice. The two cross-divisional projects were then combined into one project.

5. During a rollout of our software, a project manager could not be convinced that detailed planning over several years with exact work packages scheduled to the day was not useful. The project manager actually created a b with almost 1,000 work packages and named resource assignments. In the steering committee, the planning was actually always presented as accurate and without risk. Any deviation was compensated with high effort for the entire remaining planning. I had nothing but complaints about the effort involved in this planning. But at one meeting, the software did find a problem that the project manager had not considered: One of his key resources would be helplessly overloaded in 18 months. Nor could the AI find a solution to capacity planning for this resource: The employee simply retired in 18 months. 

6. At one company, special apps were used to monitor very closely whether employees were correctly performing their actual times for the activity allocation prescribed in the group. Those who forgot were reminded. A department manager was always able to correctly prove that all his employees in a project reported back absolutely correctly. One project manager had doubts about this recording. I pointed out to him that our software has an option, supported by a complex algorithm, where the employee can simply enter that he worked 40 hours this week. The algorithm then calculates what the optimal time would have been and generates the appropriate time entries on the employee's behalf (this feature can also be turned off). I advised the project manager to schedule a work package for the next month titled "Picking Noses." At the end of the month, it could be shown that two employees had really spent 10 hours picking their noses, based on the time tracking. The algorithm, designed to facilitate time tracking in "problem" cases, was then turned off. 

7. In an agile project, an earned value analysis for a project showed an extremely positive value. The agile team performed much better and generated more "value" in the project than any other project in the group. A detailed analysis of this, very positive, variance revealed that the team had confused the sprint in JIRA^® and had always lived two weeks in the "future".

8. An administrator of an on-prem customer system reported to our administrators an unusually high processor utilization of the system - around the clock. To this end, it is important to know that Can Do, through its ability to plan imprecisely, constantly simulates all future arising scenarios of all projects in order to present the most probable cases to all users in real time. However, the possibilities are not infinite and especially on weekends, when the least probable situations are simulated, the system practically comes to an end, it has calculated and evaluated all the possibilities. But not with this system. Even on weekends - when there was no user in the system - the server used all resources to calculate with high priority. Naturally, we suspected a flaw in the complex structure of the algorithms and started to analyze it. The problem was that a department manager simply recorded all tasks, even activities of half an hour, that he wanted to do with his department sometime in the next year. As a deadline for implementation, he simply typed in the year as a number, which is possible in Can Do. Thus, for 500 work packages all due sometime next year, he created a combinatorial variety that would overwhelm any computer to calculate the probability of how it would really go. The user didn't do anything wrong here, the software designers just didn't expect anyone to do this. The algorithm was then extended so that another algorithm recognizes when it is no longer worthwhile to calculate all possible scenarios. Then, with a correspondingly high probability, the improbable scenarios are generalized in such a way that the result is meaningful, but not entirely accurate. This emergency algorithm has not yet been used, especially in the extremely powerful cloud systems. 

Conclusion

(Hybrid) project management with Can Do can achieve a lot - in everyday project work as well as in the presentation of offers. The ability to use this PM software sensibly is in demand. Of course, Can Do supports you in this! You want to know everything about Hybrid Project Management and Can Do as well as about the connection between sales and PM? Let us advise you without obligation - just get in touch!

Our two-piece at a glance:

• Part 1: Why a good project presentation makes offers more attractive
• Part 2: From experience: examples of how not to do it (this posting)