In the first story of this series, I approached a possible danger worthy to take in consideration regarding the management of goals in software development projects: “How can we fail to see the objective reality when setting project goals” (https://medium.com/@alexandrupop_13949/algorithms-of-fail-story-1-b8e2b565c8f4). Now for my second story I will try to brainstorm again on the same topic but from a slightly different angle: the crucial importance of keeping an eye on initial project goals for the entire PDLC (Project Development Life Cycle) and in what conditions a change of initial goals is justified.
STORY 2. How can we fail to keep focus on project goals? When to consider a change in this matter as justified?
Let`s start “upside down” with an axiomatic conclusion: When we fail to keep focus on scopes (project goals) we can easily end up with slightly different outcomes. This means we slipped from the ideal trail, and surely did not wanted this to happen. We cannot be in disagreement so far.
If additional technical developments will occur along the implementation phase of the project without officially upgrading project goals section, there is a good chance that the outcomes will divert from the initial development trajectory. !NOT OK! Why? That means it is possible for these changes to affect the primary established goals of the project. If so, we can speak about failure in achieving primary project goals.
How “Agile” do we act?
It is very important to state, that Agile environment (1) allows us to modify the primary project goals in certain conditions, BUT ONLY with a carefully regard to operational targets, and in close collaboration with the stakeholder. How we do it? See PMBOK (Project Management Body of Knowledge) (2): Chapter 2 — Scope Management, Chapter 8 — Risk Management and Chapter 10 — Stakeholder Management. Keep in mind, that there are crucial synapses to take care of, when approaching scope development of a project.
The ethical point of view. If you do it, do it right.
Why do I bring ethics in such a story? Because ethics principles empower us to make the difference between right and wrong. “You got to go down a lot of wrong roads to find the right one”. True that. That`s really one of the reasons for me to write this “before-the-wedding” story @ showing off some hidden chances of errors in order for you to avoid them.
We will assume another axiomatic sentence according to which, the stakeholder or sponsor is aiming to pay for a certain result as assumed and contracted. Almost every deviation from the initial project goals will bring out “strings attached”.
Suppose the project is on-going and in the meantime, the development team find a better technical solution, capable to influence positively the project result. They strongly believe that the new solution will bring added value to the project scope. Otherwise the new scenario will be not valid and need to be turned down asap.; it`s never ethical to change for the worse, isn’t it?
Ok, we decided the new solution is superior. Now what? Now we have to think in term of change management possibilities. What will we do?
The ethical approach will be to make steps towards the best outcome. Why is that? Because we`re living in the era of Dataism (3) and radical tech advancement. Because if you`re not the best, someone else will be. Because Agile environment empower us to act incremental.
In the same time we need to think along with PMI`s PMBOK (Project Management Body of Knowledge) which is probably one of the best project management methodology so far. So, what the PMBOK tells us to do in this situation? Well it`s tricky, but we must like tricky if we want to innovate?
Let`s have a look again on desired result. Our main scope as project managing team will be to touch the project scope in the designed time frame together with managing all the PM micro-processes involved. Here we have to face the “nice” aspects of the risk management. The risks related to modify important issues of the product could affect the PDLC (Product Development Life Cycle) milestones and furthermore stakeholder expectations.
“Dirty” managing of stakeholder expectations
In this situation, we have to deal with the paradigm of cognitive dissonance. In psychology the cognitive dissonance is “the mental discomfort experienced by a person or entity who simultaneously holds two or more contradictory beliefs, ideas, or values. This discomfort is triggered by a situation in which a person’s belief clashes with new evidence perceived by that person. When confronted with facts that contradict personal beliefs, ideals, and values, people will find a way to resolve the contradiction in order to reduce their discomfort.” (Wikipedia) Well, we have to manage this cognitive dissonance issue which is practically part of risk management. From the stakeholder point of view, we have to manage the project for the best possible outcome and on the other hand our team needs to be in every way efficient (technically and financial) in order to monetize the efforts invested.
Ok, one will way, it`s simple: we present the stakeholder our new solution, he will probably agree with it and the Agile methodology will show us how to do the changes in the right way. True… but (there`s always a “but”), in most such situations, the new solutions will bring changes to project goals. Changes could refer, but will be not limited to: longer development time, increase of budgets, new risks and other needed resources maybe.
Now I will come with an objective question: will the stakeholder be willing to accept these risks? Generally speaking, projects are bonded with precise numbers like deadlines and budgets. Here we are entering in the realm of change management and negotiation management. New challenges will follow, new problems will occur. This is why, we need to think twice before deciding which tactic to adopt. Is the new solution much more efficient in order to empower us in switching the plan and go incremental? Or maybe a better choice for us will be to go with the initial plan, and chose to make further developments as soon as the project will be finalized? Kinky stuff right? Well we need to seriously take in consideration this important question and discuss it together with the team and the stakeholder representatives, because some milestones can be crucial.
One more argument to consider is that, the same Agile environment strongly supports the idea of MVP (Minimum Viable Product) (4) to be finished and then polished further.
Now we are in a better position in order to decide the best tactic to be followed for solving the issue of cognitive dissonance in SW development projects.
The “wind of change” point of view
In my opinion, the best solution will always come after analyzing data. Carefully take in consideration all the initial conditions and milestones in relation with forecasted ROI (5). In this way, we make sure that we have all the data in the equation before trying to solve it. “Marketing without data is like driving with your eyes closed” — Dan Zarrella (marketing evangelist). This rule can easily apply when making any important decision also in project management. If we like it or not, we`re living in the era of “0” and “1”, developing this new religion named “Dataism”. And of course, we know the initial plan and project scope was developed in a keen relation with an operational plan which have to run as forecasted in order to delight the stakeholders and their purposes.
In conclusion, my opinion is that the stakeholder should be presented the new solution and outcomes together with all risks associated (like more resources needed, human or financial or maybe, a longer period of time for the project to be finalized). If in this new scenario the project will need to support a redesign of the PDLC (Project Development Life Cycle) (6) and possible a supplementation of resources, then yes we need to take in consideration to be “Agile” and go with the “wind of change”. If the stakeholder and the numbers will say these risks cannot be supported, then we probably decide for the best to go with the initial strategy and discuss further solution after the project is completed and running. The stakeholder will also need to align the operational strategy to our new proposal.
Sometimes it`s complicated
However the approach above will not be not sufficient in every particular situation. In some cases, much complicated situations can occur. Maybe the efforts to implement a new technical solution on-going, will be considered too expensive to deal with. In this particular situations, the stakeholder is required to make an in-time decision, given all the technical possibilities and risks. Now the stakeholder is the one to handle the wheel.
No matter how important improvement possibilities are for the product, they should never jeopardize operations.
The surgical scalpel of risk management in operational activity
We already concluded that the stakeholder will make the decisions based on data. Even if they will have all the needed data in order to make sound decisions, it`s always difficult to make a choice in such difficult conditions.
In order to approach these complicated challenges, we need to exit the area of project management, and enter in the financial analysis zone, where we can easily deal with the “0”`s and “1”`s. Why? Because risk management is highly linked with financial management and they have together certain methods to help stakeholders in making best operational decision.
Before dealing with risks, we need to measure them. The total risk can be measured using standard deviation methods. In order to maximize the expected utility, any stakeholder will try to obtain the optimum balance between risks and return (ROI) (5). If there exists a modality to reduce the risk and maintain the return at the same level, investors will use this possibility. On the other hand, the SML Theory (Security Market Line) (7)states that, any investor is rewarded ONLY for the risk taken (or systematic risk). So, they will need to sleep on it before deciding.
Anyways, this is already far to complicated for me, so I will let the stakeholders deal with it. It`s exactly their job to do it. They will probably have financial experts alongside, ready to help. Thus I just considered useful to have a peek of the big picture in my story, because “outside the box” is always best seen as familiar.
Our generic knowledge can help us to think outside the box, but before doing that we need to nurture our own values.
(1) Agile software development: https://en.wikipedia.org/wiki/Agile_software_development
(3) Dataism: https://en.wikipedia.org/wiki/Dataism
(5) ROI (Return of Investment): https://en.wikipedia.org/wiki/Return_on_investment
(6) PDLC (Project Development Life Cycle): https://en.wikipedia.org/wiki/Product_life-cycle_management_(marketing)
(7) SML (Security Market Line): https://en.wikipedia.org/wiki/Security_market_line
– – –
Alexandru Pop @ Dental Marketing
dental marketing evangelist
+40 770 360 998
– – –
– – –