Breaking down and planning big tasks (e.g. for exam revision)

Posted on By Mark Wilson

In common with many young people in households across England and Wales, for the last few weeks, both my sons have been taking their end-of-school exams (Scottish schoolchildren finished theirs a few weeks ago).

My youngest son had more than 20 exams for his GCSEs; my eldest had eight for his A-Levels. On the lead up to these (and between them), there was a lot of revision to be done.

Creating a plan

Back when they were sitting mock/trial exams, we noticed that schools don’t teach young people how to plan. At least not based on my experience of two state secondary schools in Milton Keynes and Northampton. They might provide a list of topics, or even a per-subject “revision timetable” but my wife realised fairly early on that our sons could just see some dates, and a massive task ahead of them.

So, we sat them down, and helped to worth things through. Using Excel of course (other Project Management tools are available, but probably overkill)!

  1. First, look how many weeks there are until the exams. The days are your columns. Use borders/shading to see the weeks and weekends.
  2. Then, look at the subjects you need to cover. Those “swimlanes” are the rows. Break each swimlane into 3 rows: daytime; after school; evening.
  3. Then block out the time for actual school, part-time work, sports activities, holidays, etc.
  4. You can now see the amount of time that’s available for revision/study and populate each spare block with one or more topics to cover within each subject row.

I expected some push-back, but was amazed how positively they took on the advice (to the extent that they seemed to work it out for themselves and created their own plans when it came to the final exams).

It’s simple project management!

What we taught them to do was effectively basic project management. It’s effectively using a Gantt Chart to illustrate the schedule for completing a bunch of tasks, along with the resource availability and constraints.

This is a life skill but also a business skill. It amazes me that this isn’t taught in schools (even pretty good ones). Or perhaps it is, but it’s lost in the teenage air of nonchalance!

Featured image by Eric Rothermel from Unsplash.

Step back from the problem and think about what “good” looks like

Posted on By Mark Wilson
This content is 2 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A few weeks ago, I sat down with a Chief Information Officer (CIO) who has a problem. He’s in the middle of a messy “divorce” (professionally, not personally). He is transitioning services from a shared services agreement with another public sector body to a new managed service. His own organisation’s IT maturity is low. There’s an expectation that the new managed services partner will take on everything (except it’s not in a state that is ready to take on). And the shared service provider is both making transition difficult (preserving its revenue stream) whilst ramping up the price to carry on providing services. The divorce metaphor is very apt. 

I was brought in (alongside a colleague with relevant sector experience) to help smooth the pain. I needed to understand what’s holding up the process – why is it so difficult to provide basic information for the managed services provider to take on the service? What are the gaps? How quickly can they be filled? And what is needed to move to the next stage? 

It’s not my usual role, but I’ve been around this industry long enough to be able to take a step back, look at the problem, and try to work out what “good” looks like. 

The challenges

The CIO presented me with two challenges: 

  1. Visibility – of what’s happening. What will be done by when and how far off the target is the transition?
  2. Passiveness – don’t just sit and wait. Bang down some doors and ask for information. If it’s not forthcoming, then flag it. There is no time for delays. 

Searching for a solution

The next day, I was mulling over the issues and I bumped into a friend (on the market in the town where we both live). We went for a coffee, and I told him about my problem (without compromising any confidentiality). My friend has a military background, followed by IT Service Operations and, more recently, security (he’s a Chief Information Security Officer – CISO) so I shouldn’t have been surprised by the advice he gave me. The way he saw it was that there are a bunch of service transition “packages” but the business as usual (BAU) service isn’t complete. Meanwhile the CIO has no visibility and would like to see where things are and the plan for where they will be.

After our conversation my mind was clear. I needed a way to track progress. I wanted a dashboard to tell me the state of each service component or process. Then, the applications, servers and other infrastructure could fall in beneath – but I needed to know there is a service to transition them into. 

There are many problems with dashboards (though the etymology of the word is about protecting riders on carriages from what might be thrown at them from below… so maybe that’s quite appropriate after all). Red/Amber/Green (RAG) statuses can be problematic too (both for cultural reasons and because of accessibility, although that can be overcome with appropriate design). But I didn’t want perfect – I needed functional. At least for the first iteration.

The chosen approach

The Microsoft-focused Solution Architect in me was thinking Power BI but I lacked the skills, time and access to licenses. I needed something that could be developed quickly and updated easily. My initial PowerPoint deck with, “this is what we said we would do”, “This is where we are today” and lots of red, turning amber then green was quickly pushed aside by a colleague in favour of Excel. In fairness, the world runs on Excel – and that’s not necessarily a bad thing. With the addition of a few formulae, some data validation and some conditionally formatted cells, we soon had a dynamic report. It highlights missing information. It highlights support status. It highlights key dates (and missed dates – because I’m also realistic).

Answering the exam question

The summary sheet should answer the CIO’s visibility issue (once it’s securely shared) and constantly pushing for the detail should strike out any perceived inactivity or a lack of initiative.

It’s not innovative, but it is elegant. And it works. 

So I have the tech in place – now for the difficult bit (the part that involves people) – dragging out the missing information to turn cells from red to amber to green. And the good thing is that, based on a meeting yesterday, it feels like there are a bunch of people in the managed services organisation that can see the value and are invested in the solution (they are even adding sheets for extra information – like tracking risks, issues and dependencies). That’s half the battle. “All” I need now is to get the various projects that hold the information on the various applications, servers, etc. to join in.

I may return to this subject with an updated post when everything goes live. Or I may not, for commercial reasons, but here goes… wish me luck! 

Featured image: author’s own.

Weeknote 12/2021: IT architecture, design thinking and hybrid work

Posted on By Mark Wilson
This content is 3 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve tried writing weeknotes a few time over the years and they have been pretty sporadic. So, let’s give it another go… this should probably be weeknote 28 (or something like that) but it seems last year I named them after the week number in the year… so let’s try that again.

Because I haven’t done this for a while, let’s add some bonus notes for last week too…

Last week:

This week:

  • I published my long-form blog post on developing IT architecture skills, spun out from conversations with Matt Ballantine (@ballantine70) but also part of the work I’m doing to develop my team at risual.
  • My technical training was interrupted to complete the Microsoft Catalyst pre-sales training. It started off as what I may have described as a “buzzword-filled gamified virtual learning experience”. Then, I started to learn some consulting skills as Rudy Dillenseger brought Design-Led Thinking (aka Design Thinking) to life.
  • It was interesting to see Microsoft recommending the use of Klaxoon with Teams when facilitating remote workshops, which made me speculate about the future of Microsoft Whiteboard.
  • Was a week of virtual calls – even in the evenings. I had Zoom calls with British Cycling and for some financial advice but also a really pleasurable couple of hours on Signal chatting with an old mate I haven’t seen or spoken to in a while, who now lives overseas. It was definitely one of those moments when I appreciated a good friendship and it made me think “we should do this more often”.
  • Just when I thought I’d handed off some project management duties to a real PM, they bounced back at me like a boomerang…
  • The UK Government’s comments on returning to work (ahem, we have been working, just not in the office) reminded me of a post I wrote at the start of the year. Hybrid working is the future folks – we ain’t going back to 2019…

The last couple of weeks’ photos

When is agile not Agile? And why Waterfall is not always wrong!

Posted on By Mark Wilson
This content is 4 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

In 2004 (when I started writing this blog), I was working for a company called conchango*. The developers talked a strange language – about Scrum and XP – and it was nothing to do with Rugby Union or Windows but it did have something to do with sprints…

That was my first encounter with Agile software development methodologies. Not being a coder, I haven’t done a huge amount of agile development, with the infrastructure projects I’ve been involved in generally being run using a traditional “waterfall” approach.

These days, things are different. There’s a huge push for Agile projects and the UK Government Digital Service’s Service Manual even says:

“You must use the agile approach to project management to build and run government digital services.

Agile methods encourage teams to build quickly, test what they’ve built and iterate their work based on regular feedback.”

Agile and government services: an introduction

There’s also a lot of confusion in the marketplace. Colleagues and clients alike are using the word “agile” in different ways. And there’s an undertone that agile is the one true way and waterfall is bad.

No!

Agile/agile/agility

Let’s start off by comparing uses of the word “agile” (in IT) and what they mean:

  1. Agile (big A) often relates to a methodology – for example APMG International’s AgilePM project management methodology or the AgileBA approach to business analysis – but really they have their roots in Agile software development, with the Agile Manifesto, written in 2001.
  2. When we talk about being agile (small a), it’s a mindset: the approach taken. Literally, being able to adapt to change and to move quickly. We might use Agile (big A) approaches to help increase our agility (small a).
  3. Agility is about reaction to change. Many business want to be agile. That doesn’t mean they only run projects with Agile approaches. It means they want the ability to flex and change in line with business requirements.
  4. And then there’s the UK public sector. Specifically Police, who for some reason refer to what the rest of us consider to be remote/mobile working as agile working (as shown in this Agile Working Policy from West Yorkshire Police). That’s just an anomaly.

So that’s Agile/agile/agility sorted then. There are Agile frameworks/methodologies/approaches to delivering outcomes in a more agile manner, to increase organisational agility.

Agile=good, waterfall=bad?

Now waterfall. If Agile, is the one true way, waterfall must be old hat and avoided at all costs, right?

Not at all.

Agile projects work well for quickly creating a minimum viable product (MVP) and iterating development – for example as a series of sprints. They are great when there is a known problem but the requirements are less clear. The solution can evolve in line with the definition of the requirements. The requirements may change as the solution develops: respond to market changes; adapt to new requirements; fail fast.

But some projects are less defined. In a 2018 blog post, Matt Ballantine (@ballantine70) referred to unknown problems with unknown solutions as tinkering. That seems fair – if you don’t know what the issue is, then you can’t have a solution!

Similarly, unknown problems with a known solution. That’s nonsense. Or “WTF?” as Matt so succinctly puts it in his 2×2 diagram:

Matt Ballantine's 2x2 diagram of which path to take, including Agile and Waterfall approaches
Matt Ballantine’s 2×2 for which path to take, including Agile and Waterfall approaches (used with kind permission).

You’ll see though, that there is a place for waterfall project management. Waterfall works when there is a known problem and a known solution. Instead of constantly iterating towards an end, work out the steps to go straight there. It will almost certainly be more efficient. Waterfall projects are based on the golden triangle of time/cost/quality (which together define scope). A known deliverable (scope) bounded by how fast/cheap/good you want it to be – and there’s always a trade-off.

So there we have it. Agile is not a silver bullet and there is still a place for waterfall projects.

What to use, when?

In my line of work, Cloud Transformation might appear to use a combination of Agile and Waterfall approaches. We might create a virtual datacentre in Azure or AWS and take an iterative approach to migrating workloads but that’s still really just Waterfall with incremental delivery – even if a Kanban approach is used to inject some urgency! Similarly migrating batches of mailboxes to the cloud is just iteration, as is a programme that’s adopting Office 365 workloads one by one. An Agile approach comes into its own when we think about Business Transformation, or Digital Transformation, where we can define an MVP and then use sprints to iterate development of a set of new business processes or the digital tools to deliver those processes in a new way.

Further reading

For a clear definition of Cloud, Business and Digital Transformation, see my blog post from last year: “Digital Transformation – it’s not about the Technology“.

* The small c is not a typo – that was the branding!

Why landscaping my garden was just like an IT project

Posted on By Mark Wilson
This content is 5 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Over the last few weeks, I’ve been redeveloping the garden at home and the whole experience has made me reflect on the way that IT projects are often delivered…

Who’s been developing the garden?

Well, when I say “I’ve”, that may be pushing it slightly… I paid other people to do significant chunks of it but that’s the first similarity. I started work and quickly realised that it would a) take me a long time and b) involve the use of tools and machinery that I don’t have so I needed to engage specialist assistance.

This is just like my customers who have something in mind that aligns with their strategic goals and objectives but they lack the resources or experience and so look externally for assistance.

Getting some quotes

Having decided that I needed help, the next step was to get some idea of what it might cost. After speaking to a selection of potential contractors, I knew that my budget was hopelessly optimistic and I’d either need to scale the plans back or dig deeper into my pockets.

Again, just as in my professional world, everyone has their idea of what something might cost but sometimes that’s just not realistic.

How quickly can we start?

Having agreed on a price and a scope, the next question was how soon? Actually, for me this was pretty good: 2 weeks to start and it should take about 2 weeks. Great. Let’s do this.

In my professional life, I come across procurement periods that can run for months but then the project must happen right now. It’s not realistic to expect a professional services company to have people waiting around for your order (if they do, then maybe ask why). Expect to take a few weeks to engage.

The flurry of activity

The big day came. My drive was filled up with a skip and several tons of aggregate, sand and cement. Materials came and went. People were on site. Earth was moved. Things happened.

It always feels good when something becomes real. Progress on any project is good, especially after waiting a while to get going. But don’t expect a smooth ride the whole way…

The first sprint delivered

Whilst my family took a break, work continued at home. Drainage was installed, wooden sleepers were built up into steps and walls and a stone patio was laid.

That sounds like a successful first sprint. Step one completed, demonstrable progress and a milestone payment due.

Slippage

But hang on, we’re already 9 days into a 2-week project and there are still many items on the backlog. The weather had either been too wet or too hot. And there were delays from the skip hire company that led to inefficiencies in removing materials from the site. We were making progress but the timeline (and so the budget) was starting to slip

Many projects will have unforeseen issues. That’s life. Managing them is what makes the difference. And the key to that is communication between client and supplier.

Scope creep

What about the electrics? I had already spotted that they were missing from the quote but there was armoured cabling to be buried before the garden was completed. And that meant bringing in another contractor. Thankfully, he had worked with the landscaping team before, so he could fit around them without delay (at least for the first fix).

More contractors mean dependencies. Even when teams have worked together previously, there will be some complications to work out. Again, good project management helps.

When will this end? And what about the budget?

Sprint 2 was more of a jog. There was still earth to move, a pergola to be built, a concrete base for my “man cave” to be poured and turf to be laid. Time was ticking – the gap I’d left between the landscaping and the project work packages I was due to deliver myself (log cabin construction, garden furniture arrival) was shrinking – and with work taking place on a time and materials basis the budget was stretched.

Time for a meeting. Let’s agree what’s still left to do and how long it will take, lock down the budget and push towards completion.

I have to admit this was frustrating. But I’ve seen it in my world of IT too. Want a fixed price? Be prepared to pay more as the risk taken on by the organisation delivering the work needs to be factored in. Time and materials can work both ways (finish early, pay less – or to project over-runs) and after a while, patience will wear thin. Again, communication is key. Establish what’s left to do in the agreed scope, nail down the timescales and push for completion.

And as for the other work packages, very few projects exist in isolation. There’s nearly always an entire programme of works to deliver to meet the stated goals/objectives. Some realism is required about how dependencies will align because if you expect the various work packages to run on from each other, you should be prepared for the occasional disappointment.

Phase 1 complete

Three and a bit weeks after work started, phase 1 was complete. And it looked great. All the pain was worthwhile. Just in time to start construction of the log cabin on that base.

phase 1 of the garden completed

60% over time, 7% over budget. Not wonderful stats but also not atypical.

Postscript: Phase 2 delayed

The log cabin arrived on time but was damaged on delivery. And it would take 2 weeks for a replacement roof apex to be manufactured and shipped. With most of the materials on-site though, it needed to be built as far as it could be and then wrapped up to protect it from the elements.

Sometimes, even the best planning can come undone. Supplier contracts might help with speedy resolution of issues but sometimes there’s nothing to be done except to sit and wait…

Using the Microsoft Project calendar to block out time when people are not available

Posted on By Mark Wilson
This content is 9 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I hate Microsoft Project.

I mean, as a tool it’s OK, but it’s idiosyncratic and time-consuming to use; and even copying/pasting information is not as straightforward as it should be. Besides which, far too many people confuse a Gantt Chart with a project plan… and I blame Microsoft Project for that…

When I was at Fujitsu, I avoided having Project on my PC. If I didn’t have a license, I couldn’t edit plans… I could only view them. Unfortunately I can’t get away with that any more and, tonight, I lost most of the evening to some edits that went wrong with tasks getting split across days (I think I changed the working hours to reflect the hours we really work… but that messed something else up).

Anyway, I digress. Something I did find this evening was a really useful article describing how to change the working days for a Microsoft Project calendar. Using this I could not only add bank holidays that were missing in the standard calendar, but add the days that I’m not available to work on the project – for example because of annual leave, or other client commitments – so that the plan couldn’t allocate tasks to me on days I’m not booked to that customer.  You can also edit dates that people are available to work on a project directly (I don’t like referring to people as “resources”) but that doesn’t take into account odd days here and there of non-available time.

Next time though, I’ll leave editing the plan to the Engagement Managers…

The importance of good communications for project success

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Once or twice a month, I travel to Manchester for work.  I usually get around by tram (Metrolink) when I’m there – there’s a stop close to our office and its convenient for travel to/from my hotel and the railway station.

Manchester’s tram system is being upgraded at the moment and, last week, I was amused by posters asking passengers to “bear with us whilst we make Victoria posh”:

As much as my southern sensibilities (actually, I’m from the East Midlands) cringe at the idea of “making something posh”, in fairness to Metrolink, they do have a great series of communications around their project (and whoever is responsible clearly has a sense of humour). One of my favourites is reproduced below:

“Dear [customers]
It can be fast.
It can be slow.
You can measure it in feet, inches, weeks, months and years.
And, occasionally, in leaps and bounds.
It’s going to take a little time.
And a lot of hard work.
But, rest assured, it is moving forwards.
Creating something better for us all.
So thank you for your patience.
And while our network is undergoing this transformation, we’ll keep you up-to-date with information.”

I like that poem, and I started to think about other applications for its use… something to consider for my next IT transformation project, perhaps – because good communications are vital to project success (and so many updates that I see are just dull walls of words).

Fixing the Apple iOS SSL bug on a jailbroken iPhone, without upgrading

Posted on By Mark Wilson
This content is 10 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

My iPhone (4S) is jailbroken.  I won’t go into the details of how I did it as it changes with every release but I currently run iOS 7.0.4 and I used the Evasi0n method. Unfortunately, Apple has a pretty shocking bug in that version of iOS which means SSL transactions are not secure.

I didn’t want to go to the hassle of upgrading the OS, then jailbreaking again and, luckily, there is a workaround for fixing the iOS SSL issue on jailbroken iPhones without updating to iOS 7.0.6 (or 6.1.6) – although by the time I get this post written, 7.1 may well have hit the streets…

  1. Launch Cydia
  2. Switch to the Manage page, then select Sources
  3. Add Ryan Petrich’s repo (URL is http://rpetri.ch/repo)
  4. Go back to Manage and select Sources
  5. Search for SSLPatch and install as usual
  6. Restart SpringBoard when prompted

To test the patch (before and after), use the Goto Fail Apple SSL bug test site.