I\'m making a Post-mortem analysis and I\'m drawing a blank for the lessons lear
ID: 3564265 • Letter: I
Question
I'm making a Post-mortem analysis and I'm drawing a blank for the lessons learned relating to these incidents. Please Help :)
In a project managment world, how can the following be avoided or prevented and what lessons can be learned by it:
1. Equipment being delivered by vendor is late and took twice as long as expected?
2. Software will cost twice as much becuase the vendor came out with a new release that cost more, and they no longer sell or supporting the older version?
3. Construction for computer rooms, labs, and building modifications have been impacted by a disastrous storm which has had the ripple effect of sucking up much of the construction materials and labor in the country and increasing cost and costs for all construction-related tasks and materials have doubled, and construction tasks will have a one month delay in their start date.
Explanation / Answer
1) Equipment being delivered by vendor is late and took twice as long as expected
Building software systems is very different from building physical structures. That is, the implementation is very much different. While for example building a huge tanker, you do lots of relatively simple (not easy though!) tasks, such as welding parts together by a robot or by hand, tightening all the nuts and bolts, painting, do the decoration by carrying in all the equipment and furniture and such. All of this is very simple stuff to do, really.
However, when it comes to software, it gets much more complex. For example, how exactly do you implement the secure login and user credential storing part of the product? What libraries and tools can you use? With what libraries and tools are you familiar with? How exactly do you go about writing the hashing + salting function and how do you ensure it is secure? You can do this in so many ways that it's impossible to set any actual practical design patterns for these kind of things. Yes, the said design patterns do exist on a smaller scale as "best practices", but every single software system is very different from the others, and the field advances and changes at so rapid pace that it's essentially impossible to keep up.
When building a house, you don't really run into such problems where you realize that the main supporting walls seem to be inadequate and need to be replaced, requiring you to demolish the progress so far and start from the base by redoing the support walls. You tackle such issues at the design phase, because it's relatively simple to predict what kind of support walls your building needs.
That is not the case with software though. You can't really design the whole product as a single entity and then implement it. The software design process is usually iterative, and the goals and requirements change as the product is being implemented and tested. Software development as a whole is an iterative process in which things usually change when least expected, and many times such changes impose challenges which require more work, more complexity and unfortunately and ultimately more money, time and hard work to get right.
2) Software will cost twice as much becuase the vendor came out with a new release that cost more, and they no longer sell or supporting the older version
The most common way for businesses and individuals to get a new operating system is by purchasing a new PC. There are many updates and patches developed for the OS over the years, but when the next major version is developed, you traditionally either buy a new PC or pay for the new version of the operating system.
Two things have ruined that simple dynamic, and both of them are Apple
Related Questions
drjack9650@gmail.com
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.