Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Business Intelligence, Digital Project Management
Which digital projects did you manage?

Which are the painful points, tips and lessons learned of your digital projects, that you can share with the PM community?
Thanks a lot
Sort By:

All my projects were digital projects, Eraldo. I could literally fill an encyclopedia with pain points, tips and tricks.

1. Never underestimate the complexity of technology, especially new one.
2. Never accept estimates at face value. The estimator padded the effort
3. Acceptance testing is rarely done thoroughly. Expect defects to be found in production.

The problem is: there are not digital projects. A project to take advantage about digital access to your organization is about artchitecute. Digital world is an interface to access to your organization then if your architecture is not ready to achieve the "zero latency" answer you are lost. Agile, Enteprise Architecture (mainly business architecture layer), Data Warehousing (today named as Bid Data) are related concepts you have to take into account to be successful. All these stuff is not new. It stated on 1990. I have participated in several projects. You can include AI into it. So, the key is architecture. If you do not take into account it you will fail. Take a look to this:

U can never do enough UI testing (well maybe you can). Key is making sure the end users/customers are 100% with the finished product, and as Stéphane mentioned, testing is rarely exhaustive.

I agree with Stéphane and Sante, but would like to add:

1. Sometimes estimates are padded, but most of the time they are too low. In software development we have a saying that the estimates from the programmer should be multiplied with pi (3.14). (Especially if the programmer thinks it is a task that should be done...).

2. Be careful with the CV phenomenon: Sometimes people in a software organisation wants to add the latest cool technologies to their CV. Thus they force the use of the technology into the project/product even if it is not solving the problem, just to be able to state in their CV that they have worked with the technology. This leads to bad software architecture that is a nightmare to maintain, and it slows down the project. If you have lots of contractors in the project this risk is even higher. Always ask why the new technology is the best choice.

3. Apply the KISS principle (Keep it simple stupid). And constantly ask the development team if they have applied the KISS principle.

Please login or join to reply

Content ID: