The Parable of the Lazy Worker

Once upon a time, the manager of a department hired a worker to help the team out as they were all working until midnight. This worker took a list of problems and started fixing their causes one by one. Over 4 months, the team started finishing work earlier and earlier until they could all go home at 5.30pm. 

Other managers very upset as they saw how lazy this team was getting. They punished the manager by disbanding the team and moving him to a department he did not like. 

The worker was very sad and decided to join another team. This time, the worker was the specialist in charge of one area of the software which had multiple bugs and problems. Again, she worked hard to fix the errors and kept improving the system until there was little to fix. Because everything ran like clockwork, she could go home on time again. 

Her boss saw this and thought she was lazy. He passed her over for a promotion and she was so disappointed she left. But she taught everything she knew to her junior staff. Now, this junior staff was very good at looking busy. Instead of maintaining the systems and running diagnostic tests, and he would take short cuts and fake the results. This led to problems for the users which meant he had to stay late to fix them. He even came into the office on the weekends to clean up the mess he made. The boss was so impressed that he promoted this hard-working staff. 

The system eventually broke down and the whole team was replaced. 

Moral of the story: 

Don't hire someone just because they're hard-working. A hard-working person who can't get the job done only breaks things faster. Hire someone who can fix your problems at the source. Learn to tell the difference. 

First published on LinkedIn on 29 Aug 2020

Can you afford NOT to have a Project Manager?

I am writing this article as, having rescued countless of delayed projects, I am always amazed at how and why projects slip. Here are the top 3 excuses:

1. "We track our activities with [Jira, Trello, Slack, etc]"
   Having a to-do list is nice - it keeps people busy. It does not, however, pre-empt issues, track timelines and hold people to key milestones.
   I love Jira - it's great for agile working and sprint deliveries. But if the end product has multi-dependencies, is expensive with a drop-dead deadline, this style of management puts a huge risk on time and costs.
   However, if time is elastic and costs not an issue, then yes, you do not need a project manager
2. "We are an Agile company. Waterfall is too old school for us"
   Let's use the analogy of building a new house without a Project Manager. There will be architectural misalignment, poor co-ordination between different suppliers which will all lead to time and cost delay. However, if it is just to put the bathroom in, that is an agile delivery.
3. "Our Tech/Engineering/etc Lead can do the job"
   The skillsets are quite different. Having a specialist to manage a project is a misallocation of resource. Just as the F1 driver would not get out to supervise the work done at the pit stop, why torture your tech lead with management?

Can you afford NOT to have a Project Manager

Can the project afford not to have a good project manager? Some quick maths: say a project has 12-month deliverable with a run rate of $100,000. If it slips by a month, that is $100,000 gone down the rabbit hole.

Generally, an unmanaged project tend to slip by more 10%. Why? Without someone watching the boiling pot, alarm bells tend to only sound when there is about 15-25% of time left to testing. At this point, there is a realisation that the product is only 40-50% done, which would result in an unquantifiable (mathematically, its a 15-35%) overrun. This would lead to the panic hiring of a project manager, and, assuming the project gods favour the company, a good one is found. 

Regardless of how efficient this new joiner is, there is absolutely no way to turn back time. This person can at best minimise the cost and time overrun. This compression of work tends to lead to quality issues and/or a reduction in features.

In conclusion, the risks of not having a good project manager are:

• Cost overruns 
• Quality issues
• Delays
• Reputational damage

So, can your project afford NOT to have a Project Manager?

When is Q not Quality?

The delivery of Quality while constrained by the Project Management Triangle is the holy grail of all change programmes. 

Source: wikipedia

The definition of Quality, however, is often complicated, especially when there is no physical product or clear monetary benefit.

For many change / transformation teams, the metrics for a Programme is about delivery - how much can the team deliver in the next n years, despite not knowing where they are today. In this case, Q becomes Quantity. 

The drive to meet a Quantity-led KPI often forces the delivery teams into shoehorning a solution by the stated deadline, whether or not the solution is scaleable to meet the enterprise needs. 

Over time, the story is the same: 

• functionality and usability suffer
• manual workarounds start to appear to plug the gaps
• the implemented work cannot be reused for other areas
• data is a mess. 
• the original team leaves

This results in management: 

• pulling the plug
• commissioning another project to replace (go back to paragraph above to rinse and repeat)
• turning the manual processes into work packages and shipping them off to an outsourcing outfit, the corporate world of sweeping dirt under the carpet

Transitioning
So to the main point - how can an organisation transition from a Quantity-driven mission to one that focuses on Quality? 

Start by acknowledging that a Quantity-driven metric, while easy to measure, may not be the best place to start. Look at past deliveries and use the lessons learnt in them. Use these findings to define what Quality looks like to the organisation. 

Ideas about Quality

Some ideas around a Quality deliverable can include:

• Is the Product a working product? Did it deliver to scope?
• Can the Product and/or it's corresponding processes and outputs be reused? 
• Is the carry over defects list something that can be resolved within the next 6-12 months? 
• How is it good, if people have to manually handle it?
• See also this article on how to identify bad data

And a bonus philosophical question: If the product does what it says on the box, but does not work due to bad data or other bad processes, did the project team do a good job?

How to get good Quality

• Change the metrics. Stop making it about how many - make it about how well solutions align to the enterprise architecture
• No Enterprise Architecture? Perhaps that's where the investment should go to first. Not enough budget? Put into play a business-aligned data architecture (by the way - if there is a strong Enterprise Architecture setup, many projects can be run using Agile methodologies).
• Spend more time understanding: the current status; other in-flight projects and their expected outcomes.
• If time is an absolute constraint, ensure that an enterprise solution is planned to replace any workarounds and invest in that solution for post go-live. Senior management's reduced appetite to fix the problem after implementation is understandable, but. like wet rot in a log cabin, is not good for the organisation in the long term
• Open communications with the senior owner and the project team so they can make the necessary calls to change or hold or stop projects
• Create a culture where people are rewarded for calling out issues. Additional time or costs in the short term may mean tens or even hundred times more savings in the future 
• Get people to cross-pollinate ideas. Get rid of silos, especially the Us vs Them mindset of IT vs Business (Users). This is best done when there are crossovers from Business into IT. And yes, there will be an investment cost in people but it's well worth it.

Remember. the right KPIs drive the right behaviours which will, in the long run, build a stronger foundation for the organisation.

9 signs of data gone bad

In my early days as a junior auditor, I could never quite understand why the accountants of the companies we were auditing would stay late everytime we were there. I initially thought that it was because we were interrupting their day. However, when I had to ask for schedules (different ways of presenting or breaking down the financial data), I realised that they were staying late to create reports that were used only annually.

The dredging up of historical data was painful for the head accountant as they had to find out what was posted during the year to a certain account, and why. Sometimes, errors were spotted and reclasses had to be made. Nevertheless, our presence and incessant requests would put them in a somewhat grumpy mood.

When I first started working in financial reporting myself, I realised why the late nights happened. Every month, errors in the ledger would create a break with expectations or budget or forecasting. I did not like this as I did not enjoy going home at 9 or 10 pm a few days every month end, for something so unnecessary. So I started my own investigations in between the reporting days.

I started by teasing out the recurring issues that had to be fixed every single month. Over the next 8 months, I managed to find the roots of the problems and would speak to the owners to eradicate the errors. Eventually, I got the overtime reduced to 0, which resulted in the team getting disbanded. No good deeds go unpunished.


In a later part of my career, I applied the the same logical thinking to data testing. This resulted in seamless upgrades as I managed to catch the bugs during before implementation (which, incidentally, were missed by the vendor's other clients). Sadly, shortly after I left the team, I heard that the governance and accountability on data change management was abandoned, swiftly followed by a severe deterioration in the quality of data. That system fell into disrepute and was never the same again.

To me, data is like the raw materials or components of a supply chain. If any single piece is of poor quality, the final product will be defective. Since data is not life threatening, unlike say a car, the same level of Quality Control is not applied.

Before fretting over data, it is important to understand if the data has gone bad. Things to consider include:

1. Manual handling/workarounds
   Ideally, this should be close to the 6 sigma (no more than 3.4 defects per million opportunities). But let's be realistic - is 3 sigma even achievable? 67 defects per 1000 opportunities. If not, there is a serious data problem - either at data capture and/or handling
2. Confusion
   Project/ change teams are constantly arguing over where to get good data OR
   are finding it hard to get the data they need
3. Multiple spends
   Requests for spend on data sourcing for various projects which are similar in nature
4. Not reusing data
   Data owners consistently having requests for similar data feeds and/or fixes
5. Data user silos
   This happens when Users do not share data and disparate reports are created. A whole new cottage industry is then set up to perform reconciliation activities. See #6
6. Reconciliation cottage industries
   When the number of operations people working on reconciliations is growing consistently or exponentially, year-on-year
7. Delivery does not match Data turnaround time
   If the data is "available" daily, but direct reports take more than 2 days to create, then have a look to see if it is a data quality or process issues
8. Upset usersTeams who have to work overtime to produce reports tend to have lower job satisfaction, higher burnout rates and less energy to focus on what is most important: understanding the data
9. Regulatory wrath
   Poor data will always get discovered as the final products, reports, are unable to reconcile with each other. 

I'll write another article on my thoughts on how bad data can be prevented, and on how bad data can be repaired.

How to spot the hidden reason for Scrum/Agile project failure

I have managed pro-bono projects and implemented multi-million dollar systems. In all of them, I faced the usual resource constraints (project triangle), scope breach and (sometimes) difficult stakeholders. A breach in good project principles, like PRINCE2, is most likely the cause - not agreeing a communication plan, not determining the stakeholders' roles, etc. All these issues are well documented and an experienced project manager is able to quickly diagnose and resolve these issues to get the project back on track.

However, there is a very rare disease that causes project failure, which is sometimes hard to diagnose. So far, I've come across this twice in my career, once as a vendor, and another time, as a mentor.

Here's how it happens. At the start of the project, one of the parties proposes to use Scrum and both sides agree to go along with it as it seems like a faster option. Most of the Scrum activities are implemented - the daily standup, user stories etc. After three months, nothing has been delivered and everyone starts blaming each other, but the project manager bears the brunt for not having a project plan à la MSProjects.

For the experienced project managers reading this, you would be asking: What project plan? This is Scrum! We use burndowns and backlogs.
And you're right. IT development teams tend towards Scrum, but the business users may not be able to support Scrum fully as they are not able to commit to the intense level of resourcing needed from them.

However, I'm not here to explain what went wrong with Scrum, nor how to set it up properly. There are plenty of case studies out there. What I want to address is when to spot the fact that a project is on the path to failure - failure that is not due to the project triangle nor due to scope or difficult people.

This hidden failure happens when you think you're in Scrum mode and someone pipes up and asks: "Where's the project plan?"

Cue loud alarm bells. At this point, be prepared for a project delay. Pre-empt this by assessing the situation earlier by monitoring:

• Releases - are these being done on a 2-3 weekly cycle?

• Testing - have users tested these releases and are issues being managed in the Product backlog?

If the answer is no to either of the above, investigate if Scrum is still viable. 
During meetings, monitor the following:

• Is your tech/vendor PM mumbling "change request" ever so often?
• Do you hear stakeholder(s) asking for a project plan?
• Have users complained about too many adhoc meetings?
• Are teams blaming each other or the project manager for delays?

If so, then the project has morphed into SDLC without the anyone realising it.

At this juncture, choices include: re-emphasizing Scrum methodologies and ensure all stakeholders buy in and commit the resources; OR call a halt to the project to re-plan a standard waterfall model. The first option is quite unlikely to work as there is a high likelihood that resources are already constrained and the different teams find it hard to meet quick delivery expectations. Calling a halt to re-plan result in a delay. It will annoy and upset stakeholders. BUT it would show a level of pro-activity on the project manager's part, and form a lesson for the organisation in how to better employ Scrum in future. The time-out allows everyone to regroup, and re-commit to the project; and with specific timelines, teams can work around their other commitments to ensure they devote specific hours to the project.

In conclusion, project managers need to be vigilant at all times to the behaviours and voices of stakeholders.

This article first appeared in LinkedIn on 5 March 2016

Welcome

Hello!
Welcome to my Change & Transformation blog. 
I'm a Change Specialist and absolutely love getting things done well, and on time.  

Do note that my experiences are distilled from recurring observations that I have round in more than one organisation, either as an employee, consultant or vendor.

Outside of my professional career, I enjoy working with charities and societies on improving their controls and processes.

Contact me via LinkedIn if you would like to collaborate.

Carolyn