Which are the painful points, tips and lessons learned of your digital projects, that you can share with the PM community? Thanks a lot Eraldo Saving Changes...
Sort By:
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
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. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
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: https://www.datasciencecentral.com/profile...campaign=buffer Saving Changes...
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. Saving Changes...
Tom BjörkholmConsultant| Knowit ConnectivityLinköping, Sweden
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. Saving Changes...
"Anyone can become angry - that is easy, but to be angry with the right person, to the right degree, at the right time, for the right purpose and in the right way - that is not easy."
