Project Confusion in Transition Management

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:

Incorporate Quality

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:  

• Corporate QA protocols are activated; e.g. QA processes tailored & defined specifically for assigned projects are followed
• Risk management protocols are followed
• QA and risk matters are communicated on time to customer /management /sponsors. Create a communications plan to keep stakeholders informed.
• Feedback from stakeholders on quality & risk issues are attended to promptly
• QA and risk assessments are discussed & examined separate from routine project development activities whenever possible

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:

1. Project team members failed to sit down to appraise risks on planned activities & tasks. The excuse being "work is Agile" & "risks were discussed" but in one go at planning.
2. Project management failed to adequately define risk ownership, and with it the associated costs /costing of materialized risks.
3. There is no formal ownership of known & identified risks. A typical chorus being "the whole Agile team is responsible" for the risks.
4. Submission of assessment of identified risks through forms - using templates from past successful submissions, became a routine that no one would want to revisit & discuss. So "why rock the boat?".
5. People saw each other as transients (due to the prevalence of engaging contract resources /expertise), & took a laissez-faire approach at work. A shortcoming without .. a teaming culture that inculcates professionalism, training, & upskilling competencies.

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:

1. Parameters. Provide for editable system /application /administrative data instead of hardcoding values; e.g. background color may be softcoded as a parameter instead of hardcoded to a specific color code.
2. Logs. Wherever possible log a record for each & every task /action /response performed. 
3. Fault reporting. Application broadcasts & accepts query as to its operating status; e.g. using SNMP on separate channels with remote access capability for maintenance & troubleshooting.
4. Interface to common incl. popular communication medium i.e. email, large file transfer, text messaging & SMS. Additionally the application may need to interface with IoT sensors & smart devices e.g. handphones. Interface incl. to virtual devices where applicable.
5. High availability e.g. use the Cloud to maintain up-time, transfer downtime risks to external provider, & manage quick releases/rollback. 
6. SSO with options to let users specify & access using their own devices.
7. Users maintain & update their own profiles in compliance with local laws, use policies, & user agreements.
8. Open APIs (somewhat) that would enable add-on applications from 3rd party developers & at later dates.
9. A permanent history of hotfixes, patches & updates since first-use, accessible to users. This may include records of e.g. formal backup of data files and restoration from backup if any.

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:

• Administrators
• Internal users
• External users

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:

• save as draft feature i.e. saving automatically a form or a piece of work & recovering from a fault with most if not all previous inputs/data intact
• import bulk data to ease data entry
• input/translate different but common file formats e.g. images, audio etc.
• output to common file formats e.g. pdf, Excel based worksheets
• friendly user interface e.g. drag & drop files, auto login /re-login with facial recognition, thumb or finger prints.

Are you ready to accede to requirements? Assuming money matters are outside your purview e.g. procurement of licenses, additional considerations would include ensuring:

1. Conformity to coding standards that will meet
2. software testing requirements;
3. adherence to software & communications security protocols & standards,
4. personal data protection,
5. maintainability ↓,
6. a consistent framework for usability & review for revision or upgrade, of the application or system.

Few pointers to think about for maintenance & maintainability of the application include:

• Whether maintained internally i.e. by the company, or
• Outsource to external vendor
• Ease of troubleshooting workflows /data processing to resolve disputes ~ use/maintenance/operational.
• Documentation; ease of access to & clarity of information; is documentation up-to-date or simply lodged in someone's head.

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:

• Reporting progress through unconventional means ie. through text messaging on a medium that is familiar, effective & comfortable with everyone e.g. sharing pdf files, diagrams, scribbling on images.
• Resolving problems without meeting formally, keeping everyone informed & updated using the same medium (additionally in our case we quietly ditched the CCB process).
• Reducing or setting aside for later- formal paperwork. 

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:

1. Plan just enough. Let the project & plans evolve. Help the project team get comfortable & agree to planning with whatever information is at-hand.
2. Lead the customer. Take time to demonstrate & tweak processes towards the Agile framework.
3. Trust the project team wholly. Most importantly trusting the customer to deliver their part.
4. Apply Agile at the level of comfort for everyone involved. There will be people who are ignorant or resistant to the approach. Work on processes instead of convincing everyone.
5. Meet waterfall obligations. This sounds counter-intuitive when applying Agile practices; however there are always protocols that must be followed e.g. contracts especially in procurement, warranty claims, billing cycles.

Success factors 

My take on our success, in addition to the above lessons:

• Customer is aware of Agile - the customer had prior organisational training but not the experience in practicing Agile; and 
• Customer is 100% willing & committed to attempt a different approach to complete the project.

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.

Agile Communications 

Stakeholders simplified communicating project performance & progress, both formally & informally primarily to:

• Report on accomplishments 
• Inform on immediate scheduled plans & work about-to-start 
• Highlight & work to resolve problems

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.

• To share our collective experience, skills, and innovation in project management. 
• To build up a generation of driven professionals to succeed us some day.

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.

A communications management plan that is in place:

• Builds confidence in communication, particularly among project team members.
• Sets the pace for interaction among all stakeholders.
• Evolves the culture & posture for the project.
• Eliminates surprises through considerate feedback-channels and constructive dissemination of information.
• Resolves communication based disputes.

Without elaborating, a project-suitable communications management plan can & will facilitate getting project deliverables to the customer effectively & efficiently. Through building better relationships, understanding & acceptance of each other on good communication terms.
 

Typical Contents

The communications management plan generally define:

• What information to communicate; this include the format, details, and to what extend communication is pursued.
• Who is responsible for the information and communication i.e ownership; this include resources allocated for project communication.
• How information is communicated i.e. medium, and the flow of communication e.g. matrix or sifted through the project manager.
• When communication will occur, and its frequency. This may include e.g. if meeting face-to-face is required, where to meet and which party will bear the cost of meeting if any.
• When to revise and how changes to -the communications management plan if any, is managed.
   

My Emphasized Contents

When drafting a communications plan I find it useful to present my thoughts firstly in an informal approach, then follow-up with a formal meeting to discuss the needs for a plan. Every project & customer will have their own style & approach to communication. And to be successful, we should consider adjusting & framing project communications to the customer's preference. The outcome of the discussion may be a formal plan, an informal plan, or just an understanding on how project constituents should & will interact.

Tip! — Always commit the outcome of any discourse to some form of records. A simple approach is to follow-up quickly with an email after a meeting, stating pertinent discourse & decision options. Keep the email thread.

In my opinion, a project communications management plan whether formal or informal should examine minimally the following:

1. Decision making — Define clearly the decision structure & process for the project, based on the approved RACI matrix. This may include e.g. who is authorized to sign-off on official correspondence, speak publicly, or append their signature on project documents.

2. Medium for interaction & exchange of information — Specify acceptable communication methods e.g. using WhatsApp for messaging, restrictions on emails such as attachment sizes, sharing passwords of drop-boxes, permissible locations for business meetings, etc.

3. Policy & Procedures for interaction — this may include document retention & referencing policies, separate channels for different grade of information e.g. 'sensitive' versus confidential information, and management of communication related impediments & conflicts.

4. Teaming project stakeholders — people gravitate naturally into communities e.g. programmer analysts, deployment teams, project administrators. In addition to official project teams, recognize the subtleties of influence, power, and affect/impact of governed & ungoverned communications within & outside the project. This is one important aspect for review as a project progresses.

5. Information radiation — Identify the goal of communication for your project e.g. one of my projects emphasized communicating QA while another simply focused on getting the right message across (right instead of correct .. for another debate). Other aspects to consider include the target audience, timeliness and frequency.
    

Reminder — Avoid getting drawn into planning too much for project communications. Start with a brief base plan. Let communications evolve, but nail down what works best for the project/teams, and plan on improving interactions & sharing of information as to whatever else is important for your project.
 

References

For a quick start on crafting a communications management plan- think foremost about which communications aspect you would want to highlight. Trawl the web for suitable templates & examples; then read further on the topic, and adapt what you find to cater to your project communication needs.

• Rajkumar, S. (2010).Art of communication in project management. Paper presented at PMI® Research Conference: Defining the Future of Project Management, Washington, DC. Newtown Square, PA: Project Management Institute.