Project Management with the Common Sense

Project Management

To sound cool, you've loads of Project Management methods for your projects available, especially with IT projects. Those are great, look cool, very advanced and sounds great, real hightech.

The problem we'll have is of course you, neither your people, have any experience in those methodologies, and some of them are really complicated and honestly, sound foreign. And you know what? If you choose a project management method, and that method sounds ... complicated or fuzzy, it'll go wrong with your fancy project.


There is another alternative. That's a special method, which is also rather cool and sophisticated, extremely expensive, but it always works with any type of work, IT, industrial or anything else. Do you know what the name is of that method?

Common sense

And if you're looking for references and examples about common sense, talk with your parents and people of their generation. It's a method of control and loads of work. And not to forget creativity.


Example of a web project

Look also: Mediator project in Preview, Project Management Methods, Corona and What's new.

Many years ago I worked for a company with the name Coovy as a R&D manager, which was located in Jerusalem, Israel. That company had an idea to combine coupons and advertisements. They wanted an advanced website for the administration and demonstrating the idea in practice. The company went down after eight months, because they couldn't find the secondary funding.

I realized the common thing about Israeli software world in that time: no discipline, no knowledge at all about methodologies and not enough knowledge about programming.

I played the Project Manager for that project and this is what I did.

  1. I hired a network manager, QC manager and a graphical artist (who could draw and paint too), and I hired temporary a secretary.
  2. I bought laptops for the owners of the project (the two owners of the company, who were brothers) and the QC manager. I bought a good computer for the graphical artist. And of course printers (one was high quality for marketing purposes), connected to a network server, which we bought too. Oh, also a web server we purchased.
  3. I invited the two brothers (the owners of the project) and held series of requirement meetings. Everything what they wanted, the graphical artist was interpreting it in the form of series of drawings. The secretary (who was male by the way) recorded and documented everything. He published after the meeting all the details, which included the recordings.
  4. The graphical artist produced drawings for the marketing, the PR and of course drawings about the screens, menus, input- and output forms and reports. Ha, ha, I was so happy.
  5. And the QC manager was creating test plans of everything he heard and what was included in the requirements document.
  6. And of course, as usual, the owners of the project didn't read one thing, but they looked at the pictures.
  7. I created a contract, which described everything, and let the owners sign it that they agree with the whole thing (in Israel, this says nothing). We also created the requirements document, which included of course all the drawings from the graphical designer, together with all the charts, tables, raw designs, etc. And of course the owners of the project didn't read a thing. The QC manager finished his testing documents of every aspect in that document.
  8. I hired a good GUI programmer and used the GUI programmer, together with the graphical designer, with the help of Visual Studio to 'translate' the drawings into screens.
  9. The QC manager, together with his piles of testing cases (on paper) was testing the GUI according he requirements with simple, but very detailed checks to see if we didn't forget anything and that everything was exactly as we agreed. He found of course some 'bugs', which were fixed in no time.
  10. With the only screens but without any data, the GUI programmer connected everything and called it a prototype (website). Ha, ha. The brothers were so happy, they were already counting their money they could earn, or so they thought.
  11. We build the functional specifications with the help of the prototype and changed it more than twenty times, because the brothers, who showed the prototype to their potential customers, and their family and friends, thought it would be better to change this and to add that and to remove whatever. After every change, I went back to the requirements and changed that too and let the brothers sign for the changes.
  12. We got easily the program flow, the logic flow, and with it we came to the database design and the program design. It was mainly a reversed engineering effort.
  13. We came with the technical specifications, which was indeed made easy and we choose for a SQL server as database layer together with web services, which works excellent and was exactly what we needed. We tested everything before hand and they were indeed the best. Thanks for Microsoft and their test labs.
  14. Then came the scheduling and 'resources'. We hired one junior DBA (I'm a DBA too, so it helps), and four junior programmers and one more senior programmer. We plan to program the whole thing in C# with Visual Studio.
  15. Because all the screens were already developed and delivered by the GUI programmer, I setup the version control in a way, that everyone (the programmers) get a copy of their part of the project. I also hired five software testers.
  16. I also organized that each programmer was seen as a unit: one programmer and a software tester (I 'stole' that idea from Microsoft, who works with programmer units. They work with a few programmers, a senior programmer (or team leader), database man, graphics man and maybe others, depending on the specialization and they are treated like one unit).
  17. They sat together when they were working. With tasks, which include rare GUI work, the graphical designer was part of that unit for that task in that time. When they indeed started to work, the software tester was browsing the Internet, while the programmer was sweating. At the end, it was opposite.
  18. The software testers were armed with the testing plans created by the QC manager, and they knew what to do. Each programming task included also programming the testing program for the software tester.
  19. Setting up the scheduling was also a question of  reversed engineering. From the functional specifications, I created an outline, which were being used as tasks (initially). Within each task, multiple subtasks were created. After that was complete, dependencies were created (one needs to finish and the other can start).
  20. I used integration as a way to allow multiple tasks to start at the same time, so there was no dependency for those programmers (and allow them to browse the internet).
  21. After the tasks were finished (I didn't hire any programmer or software tester at that point in time), I went into the resources. I use the building, rooms, computers, screens, printers, servers as resources, as well the (project-) secretary, the people (programmers, testers) as resource. Each resource had its costs (be it purchase or rent).
  22. I assigned resources to the tasks. By doing that, I could specify what their (minimum) requirements must be. For example, the computer needs to be able to do this and that, the programmer needs know this and that, the DBA needs to know and have experience in this, etc.).
  23. And the final, mysterious thing, which is called the duration of a task. The normal way is the "wet finger method", partly guessing, wishful thinking and partial experience. That's so wrong. I'm old man with loads of experience and I like to cheat in order to have control.
  24. I have my own programmers library, which is nothing else than a large book with all programming tasks you can come up with. Each programming task had the work duration (slow, normal and fast in hours), and the expected lines of code (in C#).
  25. I had detailed specifications, so it's nothing else than again reversed engineering to fill in the blanks.
  26. With this information I defined the expected size (like lines of code) of each task and the duration(s). I created three projects with the help of MS Project (slow, normal and fast track). You never know.
  27. With the scheduling, I could calculate a reasonable accurate budget. Also I had a tentative finish date of the project.
  28. After the scheduling was done, I started the process to hire the people (programmers and software testers). I also tested them in several ways. Not to doubt on their quality and knowledge, no, I needed statistics. I needed to know how fast and accurate they were, and in case of the software testers, how they handle stress and how accurate they were (also tested with phony software, which was filled with bugs by design).
  29. I updated - with the statistical information - the budget and the final deadline of the project. In those times there were so many startups, and most of them will take a year and one million dollars of costs.The brothers thought the same and they had the money already (the million) and were counting that it would take a year. My project said it'll take half a year. We were already in month two, so we had four months of development and so we did.
  30. With the statistics, I knew every hour of the day what suppose to happen with the project. And I monitored it too. I created a system of Project Health and Project Productivity and Schedule Health, which were nothing else than numbers between 1 and 10, which indicates the health.
  31. I installed a computer, which only displayed these numbers in the offices of the owners of the project.
  32. My calculations about the expected bugs didn't work out at the end, because of the programmer units I used (programmer and software tester).
  33. With programmers units, you always get tensions. After the work day, I organized team games. Teams like programers against testers, R&D against management, everyone against me; and most of them were shooting games. That went well.

This is the way how Project Management suppose to work.

Team Work

Team Work

  • I also organized each month a barbecue or similar for everyone who worked in the R&D and their families (wives, husbands, boy- or girlfriends and children). That was also included in the budget and the brothers got almost a heart attack; they didn't understand the reason for that. At the end they agreed to try it. Ha, ha.
  • The real boss for a programmer (and software tester as well) is his wife (or her husband) or partner. When such person stands fully behind the project, the poor sod is indeed fully motivated to succeed.
  • For each person in the R&D I took care that they were trained and educated to advance their own work.

This is the way how Project Management suppose to work.




In summary, what shall you do if you want to use a Project Method?

If you really think that you need to use a Project Management Method, you need to take into consideration that you and everyone in your R&D needs to be trained in such method (including and especially senior management, which includes the CTO and CEO). Also, after the training, experienced people (familiar with the Project Management Method) needs to be with you for many months, if not up to a year, as part of your R&D. It's a heavy investment.

Your answer is actually simple. You need to hire an external (educated and experienced) project manager, who'll run your projects with the common sense method.

A profile for such project manager is simple. He or she needs to be intelligent, a driven person who'll do anything to succeed, an authority figure who gets control of every aspect of the project; be it the toilet boy, the cleaner, the receptionist, the secretary, the programmers, testers, managers ... everyone.

Such person will control every aspect of your projects in simple ways. Telling someone that he or she is in control doesn't work and that's also not the way how such a person works. With their presence, everyone pays attention ... and smiles. Humor is the base of such behavior. The feeling of wellbeing, taking care for, being advanced, can learn so much more, a relaxed environment without overwork, overload, stress and more like this. Being seen as someone valuable for the company and project, having the impression that his or her opinion being heard and counted on.

Such project manager knows the R&D people, the people in the project, and also their families, their partners and such person runs around with faded jeans and a wild t-shirt. Such person, with a crazy smile and almost every time grinning, is in absolute control of the project, so such person can succeed. He or she is worth gold.

This is the way how Project Management suppose to work.

  • I knew (I did the same) PMs (project managers), who demanded an apartment near work and a car with private driver. Why? Because the PM always worked, 18 hours a day (sometimes more) to prepare anything, to analyze the previous day and be ready for the next day.
  • Many years ago in Holland they asked me to take over a failing project. After two days looking into the project, I asked the project owners to transfer the working location from wet, cold Holland to subtropical environment and they agreed with it (finally). We moved the project to Cyprus and spent the time working, swimming and clubbing. The main thing was that suddenly everyone was motivated (for the wrong reasons, but it worked) and we finished the project in record time (near the swimming pools, bars, restaurants and the rented work spaces and offices. Oh, also on the airplane.

1 thought on “Project Management with the Common Sense”

  1. Pingback: Create your website for your special project » Wim Vincken

Leave a Reply, please

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Copyrights (c) 2020 Wim Vincken | Copyright Notice | Privacy Policy | Resume | Terms & Conditions | What's New | Refund Policy
InterServer Web Hosting and VPS
%d bloggers like this: