This brief is going to read like course notes! I wrote about a lesson learned in ignoring proper risk appraisals & risk documentation in my previous blog.
I hardly hear nowadays — the words quality & risk used literally particularly when a project, stage or project phase duration is deemed short; unless quality & risk are explicitly specified in requirements. Work seems to be always in a rush, with little time to spare for thinking through what was planned the first time around. Working on projects feels a lot like routine operations. Couple with the fast pace in Agile, the notion that if it works one should just go with it again seems to be the new norm. Working like clockwork may help the team deliver any assigned project pronto, eliminate overall project risks, and minimize disruptions. But it presents a downside, among which include:
Whatever the circumstances may be to rush a project (or lagging project activities), give a thought for project risks. It is an essential management attribute of a quality project. A quick recap on dealing with project risks ~
Some structures. There has to be some form of structure when discussing risks. Consider a structured approach to administer project risks. For starters:
Give it some numbers. Create a risk score ႟. There are different means to evaluate risk. Choose a suitable approach /template e.g./wordings. Rate your risk attributes e.g.:
႟ = Risk Likelihood ✘ Risk Impact ✘ Risk Detectable
I would advocate framing risk & quality agendas when discussing project activities; especially when hard pressed for time to examine & investigate associated risks & quality concerns in separate meetings. For each prioritized risk:
"Documentation is not understanding, process is not discipline, formality is not skill." — Jim Highsmith, Adaptive Software Development
Time and again I encounter problems on work quality that are easily mitigated. I learned from my colleagues recently they incurred losses due to sub-contracting work that were not thoroughly planned.
How did that happen?
Without the facts, the case may be attributed to the management of project quality & project risks which the project team may have neglected somewhat. A broad insight of that project:
Project quality measures the effectiveness & efficiency of planned activities against common/acceptable benchmarks, best practices & standards. Quality is monitored to report progressively on developments, managed to keep things right, & controlled to deliver what was agreed/contracted. These are necessary quality processes performed throughout a project lifecycle.
The project team/manager is expected to abide & see to that:
Their project suffered losses because the only quality process which they enforced (capable of) is to report on performance. That too in reporting superficially on ongoing task status & meeting task deadlines; in spite of established corporate quality policies of both contractor & customer. A prevalent practice which I observed, is that projects tend to focus on achieving stipulated terms, & to the letter at best. A common argument for this is that project management dynamics today are fluid. Quality hence is neither managed nor controlled — structurally.
Ignoring quality i.e. planning for quality & driving quality processes, in itself is a huge risk.
Plan for Risks
Risk must be identified, analysed, monitored & controlled with risk responses pre-authorized (where applicable) & confidently put in place. This should be a process with its own framework for risk ownership, accountability, and which is as-much-as-possible independent of the project development framework. Similar to that commonly practiced for corporate QA. The reason being risk matters should be evaluated separately from reviewing, planning & tasking project activities. More so when the project framework is Agile where activities are planned & tasks are assigned as like in a single breath, with little evidence of work, & seemingly always on schedule with hardly any impediment.
The least is to integrate risk & QA paperwork i.e. taking evidence that quality procedures & risk controls are effected. QA & risk management are key to ensuring the customer gets what was agreed and contracted. And the project team truly delivers what is expected.
Their lessons learned:
Risk planning is inevitable. There should be minimum protocols to follow for each & every project undertaken. There is after all a universal risk management standard.
This brief is intended to document & serve as a general guide on what typical technology features 'to look out for' when confronted with new ICT application projects or opportunities. At a high level overview of common system functions which are necessary to implement useful tech products, gleaned from experience. These notes may be biased towards using the Cloud.
IMO a useful piece of software should be designed & developed with minimally the following broad features:
The list above surmises my preferences. Yours may differ. And there are many other features, some which are essential to consider & in detail when specifying functional requirements of a piece of application software /device /in combination. Now that the application has some form of character, who uses it should be considered next.
The application should distinguish without elaborating, the following roles:
Users have their expectations too. A good piece of application should be accessible anywhere & anytime. There are limits though if the application is dependent on something or things beyond your control (design /development /operational).
High availability & ease of use to a user would be expectations for e.g. in software:
Are you ready to accede to requirements? Assuming money matters are outside your purview e.g. procurement of licenses, additional considerations would include ensuring:
Few pointers to think about for maintenance & maintainability of the application include:
My project involves the deployment of reliant systems for aviation safety. The project was called, tendered, & awarded as waterfall. At the start of the project, there were unprecedented, IMO irrational new requirements with a mandated condition of urgency to complete the project ahead of schedule.
With unanticipated new requirements, there was a sense the project will need a different approach to management if the team were to keep to the proposed timelines. It didn't happen. Because interestingly nobody could agree nor willing to deep dive into project management methods!
So the project continues with negotiated mindless commitment to accommodate to needs, wading through waterfall demands that are difficult to compromise. Our upside of commitment is cohesive customer-vendor collaboration; developed through working in proximity. But it could easily go the other way.
This brief presents the lessons learned in introducing & adapting Agile in a contracted waterfall project. The introduction which was unintended & unplanned for. Where Agile is informally practiced.
The project eventually settled into a regime that emphasizes meeting deadlines on essential deliverables. And communicating developments particularly issues verbally & in a timely manner. Compromises were made on:
Now in its final stages, the project runs & feels like an Agile project. Where communication is key to keeping everyone updated on progress & ready to resolve problems, if any arises. It is informally Agile with prescribed waterfall submissions, minus the embellishments typical of Agile methodologies.
Our Lessons Learned
Thus far, we applied with intent the following:
My take on our success, in addition to the above lessons:
The project team continues to maintain & prescribe project management functions e.g. QA, risk assessment on work packages. Work now runs on a fast track. Yet without compromising on essential tasks e.g. audits.
Stakeholders simplified communicating project performance & progress, both formally & informally primarily to:
Tip! - Keep reporting on progress & performance to a minimum but at an acceptable level or standard. Check with the customer regularly for feedback on communications & clarity.
Vision 2020 is a global action programme that aims to eliminate avoidable blindness by 2020. It is an ambitious project & undertaking bringing together countries that support its agenda. Next year is 2020. And there is still much to do.
In 2018 reports emerged that spending too much time looking at blue light emitting screens can cause macular degeneration and other eye diseases. In 2019 there were media reports on handphone users going blind. But likely temporarily, due to prolonged use & squinting at their phones. Eye stroke as is known, may be a new cause for concern.
In everything that we do and strives to improve there will be new developments and trends - that which can throw spanners into the work. Yet, we have to continue and persevere with what we have started. In the same, or in a different form.
Just like Vision 2020, we as project management professionals too have similar roles.
Yaa! I sounds corny. But we can only expand on what we have acquired & gained - here & now. (In this space -limited to mostly PM related stuff).
Next year I look forward to give back from my profession as a certified PMP. I would need your help to get connected to charities and not-for-profit establishments. I am keen to volunteer my time for a week or two in IndoChina or Myanmar. Or perhaps elsewhere. Travel and meet new friends. And I'd be happy for any assistance to get introduced.
Wish you all the success in your projects & a Happy New Year!!
Visit PMIef.org for information on volunteering for your profession.