Managing on Shafiq Alibhai

WHPH vs Super Productivity

Mon, 29 Sep 2025 11:53:23 +0000

I’ve been trying to figure out which productivity app actually fits my workflow. Both WHPH (Work Hard Play Hard) and Super Productivity keep coming up, so I thought it was worth comparing them properly.

WHPH (Work Hard Play Hard)

WHPH is a general-purpose productivity app. It does several things: tracks your tasks, monitors which apps you use and for how long, helps you build habits, and gives you a basic sense of where your time goes. The sync between desktop and mobile happens over your local network – no cloud, no account, just devices talking to each other.

Starting a new contract — what I wish I'd asked sooner

Thu, 22 May 2025 12:07:12 +0200

I’ve been on enough contracts now that I’ve started noticing patterns. Some good, some not so good. This is a collection of the things I check before signing, and the things I wish someone had told me about earlier.

Before you sign

There are three administrative questions that can catch you out if you don’t sort them early. The first two are about checks — whether the client needs a BPSS or DBS check done, and whether they’re going to organise it. The third is about timing. Some start dates are real, others depend on the client actually getting you a laptop and sorting your access. If their setup process is slow, your start date slides whether they realise it or not.

When a Problem Is Worth Solving

Thu, 22 May 2025 12:04:38 +0200

I used to take on any project that came my way. That was a mistake.

Not every problem deserves your time, and not every client is worth working with. Over the years I’ve learned to filter opportunities through a simple set of questions before committing to anything.

Can they fix it themselves?

If the answer is yes – or if a decent blog post could solve it – then it’s not a consulting engagement. It’s a homework assignment. The value of consulting lies in the gap between what the client knows and what they need to know. Close that gap and you’ve got nothing to sell.

Self-Promotion at Work

Thu, 15 May 2025 14:30:04 +0200

Self-promotion gets a bad reputation because people confuse it with boasting. Done well, it’s just making sure the right people know what you’ve done.

Use “I” when it’s your work

If you led the project, say “I led the project.” Saving “we” for genuinely collaborative work means your individual contributions stand out when they matter.

Performance reviews are your moment

If your organisation does annual reviews, prepare a list of accomplishments before the meeting. Don’t rely on your manager to remember everything you did over twelve months.

Building a Second Brain

Wed, 11 Sep 2024 10:50:01 +0000

I’ve been reading Tiago Forte’s Building a Second Brain, and it’s one of those books that makes you immediately want to reorganise your entire digital life. The central idea is straightforward enough: your brain is for having ideas, not storing them. Everything else – notes, articles, voice memos, half-finished projects – should live somewhere external that you can trust and search.

The framework he proposes is called CODE: Capture, Organise, Distill, Express. It’s simple, and that’s the point. Most people I know (myself included) are terrible at the first two steps. We capture everything – screenshots, highlights, random thoughts – and then we never look at it again because there’s no system for getting it out.

Books that actually helped me with the people side of project management

Tue, 05 Sep 2023 04:31:03 +0000

I spent a chunk of last year reading my way through the soft-skills section of the bookshop. Not because I’d suddenly become interested in personal development — more because I was struggling with a project where the technical bits were fine but everything around it kept falling apart. Miscommunications. Teams that wouldn’t align. Stakeholders who seemed to be operating in a different reality.

So I started reading. Not the textbook stuff, but the books people actually recommend when they’re being honest. Here’s what stuck.

Security Clearance Vetting for Access to Cloud Production Environments

Tue, 11 Jul 2023 01:50:03 +0000

Access to cloud production environments should require security clearance vetting. Production systems hold live data and applications, and the consequences of compromise are direct.

UK clearance levels

Level	What it covers	Checks included
BPSS	Pre-employment screening for government asset access	Identity, employment history, immigration status, unspent criminal record
AC	Unescorted access to UK airport security areas	Identity, employment history, criminal record, government agency records
CTC / Level 1B	UK OFFICIAL assets, occasional SECRET access	Identity, employment, criminal record, financial situation, personal circumstances
SC	Substantial unsupervised SECRET access	Everything in CTC plus credit reference and MI5 record checks
DV	Substantial unsupervised TOP SECRET access	Everything in SC plus detailed interview and referee enquiries

The process

You need a sponsor — usually HR or a company security controller. They confirm your role requires vetting and that BPSS checks are complete (unless you’re doing AC). You then fill out a security questionnaire online covering personal details, employment history, finances, criminal record, foreign travel, and contacts.

What DevOps Collaboration Actually Looks Like

Fri, 27 Jan 2023 11:08:20 +0000

I spent years watching development and operations teams sit on opposite sides of every incident. Developers pushed code over the wall. Operations inherited the fires. DevOps was supposed to fix that, but most teams just gave it a new name and kept doing the same thing.

Real collaboration isn’t a poster on the breakroom wall. It’s the unglamorous daily work of making sure two groups who think differently about problems end up solving them together.

Project Initiation Documentation RACI Chart

Tue, 30 Dec 2014 15:56:13 +0000

This is a RACI chart specifically for project initiation documentation — who’s responsible for producing each piece of the paperwork that kicks a project off.

It’s based on the chart from Project Management for Dummies (Wiley, 2011), which is one of those books people laugh at but actually contains useful reference material. This particular chart maps out who does what during the initiation phase: the business case, the project brief, the risk register, the stakeholder analysis, and so on.

Stakeholder RACI Matrix Spreadsheet

Sun, 28 Dec 2014 10:53:53 +0000

A RACI matrix stops the “I thought you were doing that” conversation before it starts.

It’s a grid. Down the left side, you list the tasks or decisions. Across the top, you list the people or roles. Where they cross, you mark what each person’s relationship is to that item:

R — Responsible. The person doing the work.
A — Accountable. The person who owns the outcome and gets to say it’s done.
C — Consulted. The person whose opinion matters before a decision is made.
I — Informed. The person who needs to know after the decision is made.

Why it matters

The most common failure mode on a project isn’t that nobody does the work. It’s that two people think they’re both responsible, or nobody thinks they’re responsible at all.

Break stakeholders into smaller groups according to roles or goals

Mon, 15 Dec 2014 14:06:04 +0000

Once you’ve got your stakeholder list — the one from the stakeholder list document, filled in with names, titles, and notes — the next step is to stop looking at it as a flat list and start grouping them.

A flat list of twenty names is hard to work with. You can’t send the same email to everyone. You can’t run the same meeting with everyone. You can’t make the same promises to everyone. So you split them up.

Stakeholder List Document

Mon, 08 Dec 2014 10:19:56 +0000

Every project has people who care about it, whether they’ve signed up for it or not. The trick is figuring out who they are before they start caring loudly.

I keep a simple stakeholder list document open from day one. It’s not fancy — six columns, thirty-six rows, nothing more. But it stops you from being surprised when someone you never considered shows up at a steering group demanding answers.

Some notes on people skills and emotional intelligence

Sun, 07 Dec 2014 12:01:02 +0000

I’ve been reading up on emotional intelligence lately and collecting the bits that felt useful. Not the textbook definitions — the ones that actually change how you show up in a room.

The five things that matter

There’s a framework that keeps coming up, and it boils down to five skills: rapport building, curiosity, communication, ambition, and conflict resolution. They’re not glamorous. They’re not the sort of things you put on a CV under “technical expertise”. But they’re the difference between being someone people want to work with and someone they tolerate.

How to develop your political IQ

Wed, 03 Sep 2014 13:39:09 +0000

Most people treat office politics as something to avoid. They’d rather focus on their work and hope it speaks for itself. But the truth is, everyone is already playing the game — whether they admit it or not. The difference is between people who understand how it works and people who get surprised by it.

Here’s what I’ve learned about developing political awareness at work.

Know where you’re going

You can’t navigate an office if you don’t know what you’re looking for. What do you actually want? A promotion? A transfer to a different team? More influence over decisions? Be honest with yourself about it.

One resolution for 2014

Sat, 28 Dec 2013 22:53:04 +0000

It’s the last day of 2013 and I’ve been sitting with the question of what I actually want to do differently in 2014. Not what I should do, not what sounds good on a vision board, but what I genuinely want to change about how I spend my time.

I’ve made lists before. Five resolutions, ten resolutions, the whole lot. Write more, exercise more, read more, save more, learn a language, cut out social media, meditate every morning. By February I’d abandoned at least eight of them, and the ones I kept were half-hearted at best. The problem was never discipline. It was that I was trying to change everything at once, which is just a fancy way of saying I wasn’t going to change anything at all.

Third party assessment document

Sat, 01 Dec 2012 16:13:45 +0000

Vendor Assessment

Type: Vendor Assessment

Project Information

Field	Description	Value
Name	Enter the name
TPA: Project Name	Whirlpool project name requesting third party or service provider connection
TPA: Project Owner	Whirlpool project owner requesting third party or service provider connection
TPA: Business Area	Whirlpool business area or process supported by the third party or service provider
TPA: Service Provider Name	Service provider company name
TPA: Service Provider Contact	Service provider or third party contact
TPA: Target Implementation Date	Target implementation date
TPA: CISO	Vendor Chief Information Security Officer (CISO) or equivalent
TPA: User Directory	Choose the user directory used to manage security and provisioning of access on your internal network
TPA: OS and database	List the operating system and database used to manage Whirlpool data
TPA: Datacenter location	List the location of the datacenter that hosts Whirlpool data

OS/Database options: Mainframe, Unix, AS400, Windows, Oracle, DB2/UDB, MS SQL, Other

A Risk Assessment Checklist for Software Projects

Tue, 10 Apr 2012 07:51:08 +0000

I picked this up a while back and it’s been sitting in my notes ever since. It’s a risk assessment checklist for software projects — the kind of thing you’d run through before committing to a contract or kicking off a big engagement.

The original is a ten-page Word document with checkboxes. I’ve reorganised it here so it’s easier to scan. The categories are roughly in order of how you’d work through them: start with requirements, move through design and implementation, then look at process, people, and external pressures.

My email to Datawind, the company behind the Aakash Ubislate tablet

Sun, 22 Jan 2012 08:12:58 +0000

I prebooked an Aakash Ubislate tablet on its first day of availability. Two months later, I’m still waiting, and the email chain with Datawind’s support team tells the whole story.

The booking confirmation

Dear Shafiq,

Your Booking ID is : xxxxxxxxx

Someone from our sales team would get in touch with you and provide you with the payment and delivery options.

The commercial version of the UbiSlate would be launched in early weeks of December.

Order to Cash — What It Actually Means

Fri, 11 Nov 2011 05:15:24 +0000

I spent a fair amount of time working on SAP implementations back in the day, and one of the modules that came up again and again was Order to Cash. People throw the term around in meetings like it means something obvious, but if you ask five people what OTC actually covers, you will get five different answers. So here is my take on it — not a textbook definition, but what it looks like from the inside.

A Sample Scrum Template

Sat, 01 Oct 2011 08:40:49 +0000

I needed a simple way to track a scrum project without investing in a tool, so I built a spreadsheet template. It’s not meant to replace anything serious – just something to get the structure down on paper before things get messy.

You can grab it here: scrum-tmpl-100212

It’s got three sheets. The first is basic project info – organisation, project name, scrum master, product owner, start date. The second is the product backlog, laid out by sprint with room to track effort against each release. The third is an impediments log, so when something blocks the team you write it down with a category, date, and who raised it instead of letting it get lost in a standup conversation.

A project proposal template I keep coming back to

Sat, 01 Oct 2011 07:18:20 +0000

I’ve written enough project proposals over the years to know that the hardest part is usually the first page. You sit down with a blank document, a client’s RFP, and a deadline that’s already too tight, and you wonder where to start.

So I made a template. Not because it’s brilliant, but because it stops me from spinning my wheels every time.

You can grab the Word file here: proposal-template.doc

How we handle proposals and contracts

Sat, 01 Oct 2011 07:00:19 +0000

I’ve seen too many teams treat proposals and contracts as paperwork – something you rush through on the way to the “real work”. That attitude costs money. I’ve watched deals fall apart because someone skipped a step, or signed something they didn’t understand, or assumed the other side was on the same page.

So we wrote a procedure. Not because we’re a big company with a compliance department, but because we kept making the same mistakes.

A Sample Issue Tracker Spreadsheet

Sat, 01 Oct 2011 06:31:21 +0000

I put together a simple issue tracker spreadsheet for a project I was working on. Nothing fancy – just something to keep track of bugs, tasks, and sub-tasks without the overhead of setting up a full issue tracking system.

The idea was to have something lightweight that anyone on the team could open and update without needing special software. You can grab it here: sample issue tracker spreadsheet

It’s got the basics: issue type, status, priority, resolution, assignee, reporter, dates, and an SLA column. The sample data shows what it looks like with a mix of open, verified, and closed issues at different priority levels.

The line that separates a developer from an administrator

Mon, 04 Apr 2011 04:36:59 +0000

You learn more from your mistakes than anything else, and I have made my fair share. The trick is to actually learn from them rather than just suffer through the consequences and call it experience.

I have watched developers push code to production on a Friday afternoon because the business was breathing down their necks. The deadline was immovable, the pressure was real, and the production environment was treated as an afterthought. I have seen it happen more times than I care to count, and each time the same thing goes wrong: someone breaks something, and nobody wants to own it.

Make it free or fail

Sun, 02 Jan 2011 07:16:38 +0000

The freemium model has become all the rage in software circles. Offer a basic version of your product for free, then charge for the good stuff – premium features, extra storage, advanced functionality. It sounds like a clever way to build a user base, and for a handful of companies it has worked. But as someone who has watched this approach play out across the industry, I have my doubts about whether it is the right strategy for most startups.

Never Use a Shared Database for Development

Wed, 15 Sep 2010 08:39:58 +0000

A shared database server is a convenience that turns into a trap. Developers overwrite each other’s changes. My changes on the server break your code on your machine. Remote development is slow.

Avoid shared databases. The time you save setting up individual databases is nothing compared to the time you’ll waste debugging conflicts.

Deployable Software Is the Only Metric That Matters

Wed, 15 Sep 2010 04:11:06 +0000

We talk endlessly about improved software quality and reduced risks. But for clients and users, the only tangible asset is deployable software. Everything else – process documents, test reports, velocity charts – is noise without working code to back it up.

Note to Self -- Project Management

Thu, 09 Sep 2010 06:20:39 +0000

You can manage scope, time, cost, and quality much more effectively by basing decisions on working software with actual feedback and metrics, not just task items on a project schedule.

Completeness of the Requirements Set

Wed, 18 Aug 2010 06:40:13 +0000

A set of requirements is complete when it describes all significant concerns of the user – functionality, performance, design constraints, attributes, and external interfaces. If any of these are missing, the requirements are incomplete.

Requirements Gathering

Sat, 31 Jul 2010 11:02:19 +0000

There’s no single right way to develop detailed specifications, just as there’s no single right programming language for every application. Different projects demand different techniques. Requirements managers need a mix of skills to adapt to whatever circumstances they’re working in.

Software Development Process

Tue, 20 Jul 2010 08:26:25 +0000

The team’s development process defines who does what, when, and how.

Waterfall – activities proceed through a fixed sequence, each step depending on the previous one.

Spiral – starts with risk-driven prototypes, then follows a structured waterfall-like process.

Iterative – a hybrid that decouples lifecycle phases from the activities within each phase.

Whichever model you choose, build at least one early prototype to get customer feedback before committing to a full implementation.

Detailed Estimates Are Often a Waste

Mon, 19 Jul 2010 09:26:59 +0000

Some people believe the best way to estimate a project is to produce detailed requirements and design documents for every feature before writing a line of code. It sounds professional. It sounds thorough.

In practice, it usually turns out to be wrong. Requirements change. Priorities shift. The detailed estimate you spent weeks producing becomes irrelevant halfway through the project.

That effort becomes wasted inventory – time and resources that could have been spent building something useful instead.

Project Scope and Success

Sat, 17 Jul 2010 09:40:52 +0000

In many projects, in order to provide a reasonable probability of success, it will be necessary to reduce the scope by as much as a factor of two.

I’ve learned this the hard way. Every project starts with an ambitious list of features and an optimistic timeline. Reality intervenes quickly – resources are tighter than expected, technical problems emerge, and deadlines don’t move.

Cutting scope feels like failure. It’s the difference between shipping something that works and shipping nothing at all.

The "Yes, But" Syndrome

Wed, 14 Jul 2010 06:13:26 +0000

Every piece of software I’ve developed elicits the same two reactions when users see it for the first time:

First: “Wow, this is cool. We can really use this.”

Then, immediately: “Yes, but… now that I see it, what about this? Wouldn’t it be nice if…? Whatever happened to…?”

The “Yes, But” syndrome is universal. It comes from the nature of software as something intangible – until users see it, they can’t fully articulate what they need. Seeing the implementation triggers new ideas, new concerns, new requirements that weren’t visible before.

Productivity of all Individuals vs. Team Productivity

Mon, 12 Jul 2010 08:14:38 +0000

Software development is a complex and collaborative process that requires effective teamwork and communication. However, many software teams struggle with productivity issues and fail to deliver high-quality products on time and within budget. In this post, I will discuss why team productivity is more important than individual productivity, and how you can improve your software team’s performance by applying some proven strategies and best practices.

The Importance of Team Productivity

According to Boehm, the COCOMO cost estimation model shows that the capability of the team has the greatest impact on software production. This means that the quality and efficiency of the software product depend largely on how well the team works together. Davis agrees with this conclusion and states that “optimising the productivity of all individuals does not necessarily result in optimising the productivity of the team”. In other words, having a team of highly skilled and productive individuals does not guarantee a successful software project. There are other factors that affect team productivity, such as communication, coordination, collaboration, motivation, and trust.

Scrum in 8 Steps

Mon, 22 Mar 2010 06:52:15 +0000

Scrum breaks a product into small pieces (backlog items) and works on them in short iterations (sprints). Here’s how it works in practice:

1. Prepare the product backlog. List the features and requirements. Involve stakeholders to prioritise. The product owner is responsible for the vision and goals.

2. Estimate the backlog. As a team, give a rough estimate for each item. Planning poker or t-shirt sizes work well here.

3. Plan the sprint. A sprint is a fixed period – usually one or two weeks. In the sprint planning meeting, decide the duration, goal, which backlog items to tackle, the tasks for each item, and the hours per task. The result is the sprint backlog.

Show Your Learning on Your Resume

Mon, 22 Mar 2010 06:06:00 +0000

A degree gets you noticed. What you’ve done since then gets you hired. Here are some ways to show continuous learning on your resume:

Professional certifications. They demonstrate you’ve met industry standards and can help you stand out from candidates with similar qualifications.
Publications and articles. Writing shows you have something to say and can communicate it clearly. Use them as portfolio samples.
Presentations. Speaking at universities, schools, or conferences demonstrates communication skills. Record them and post them online.
Volunteer work in your field. Shows genuine interest in your work beyond paid employment.
Technical courses and training. List them alongside formal education.
IT certifications. Microsoft, Cisco, and similar credentials prove specific technical competence. Many employers look for them.
Foreign languages. Learning another language opens doors and shows cultural awareness. Rosetta Stone and subtitled DVDs are good starting points.

Restarting a Project from Scratch

Mon, 08 Mar 2010 05:40:13 +0000

Every programmer knows the urge: scrap everything and rewrite it from scratch.

It’s not that the existing code is bad. It’s that it’s hard to understand. Reading code is harder than writing it – you wrote the new code in your head, but the old code belongs to someone else (or to past you, who might as well be someone else).

This is why every developer on your team has their own favourite way of splitting strings into arrays. Writing a new function is simpler and more enjoyable than learning how the existing one works.

Basic Software Development Process – Points

Thu, 01 Oct 2009 16:38:48 +0000

This is the process I follow on projects. It’s not fancy, but it works for me.

Defining the requirements. Write down what needs to be built. Be specific. Ambiguous requirements are the root cause of most problems later on.
Approval. Get sign-off on the requirements before anything else. If the requirements change later, that’s fine, but do it deliberately, not by accident.
Template designs. Work out the structure and layout before writing code. For web projects this means mockups and wireframes. For other projects it means architecture diagrams and data models.
Template approval. Get the designs signed off too. It’s cheaper to change a design than to change code.
Coding. Build it.
Internal release. Get it in front of the team first. Internal testing catches the obvious stuff before anyone external sees it.
Testing. Proper testing, not just “I clicked through it once.” Automated tests where possible, manual where necessary.
Alpha release. Early access for a small group. Expect bugs. The goal is to find them in a controlled environment.
Beta release. Wider release. More users, more edge cases. This is where you learn what people actually do with the software versus what you thought they’d do.
Project goes live. Production. The real world.

The key thing is not to skip steps. I’ve seen projects that jump straight from requirements to coding and then spend three times as long fixing problems that a proper design phase would have caught.

Arsin Systems — Organisation Profile

Thu, 06 Aug 2009 06:13:53 +0000

I spent some time at Arsin Corporation, a company based in Hyderabad, India that specialises in enterprise software testing. Here’s a summary of what they do, mostly for my own reference.

What they do

Arsin provides automated testing services for large companies, with a particular focus on SAP. They’ve been around since 1995 and their clients are mostly Fortune 500 companies in pharmaceuticals, finance, healthcare, and technology.

The idea is that when you’re running enterprise software, you can’t afford for it to break. Arsin builds the testing infrastructure that catches problems before they reach production.

Some Questions to Ask Before You Join a Startup

Wed, 22 Jul 2009 12:18:17 +0000

I’ve been thinking about what to ask when someone offers you a job at a startup. The usual questions about salary and benefits matter, but there are deeper ones that tell you whether the place is actually going to survive long enough for you to care about that stock option package.

Here are some questions I’d ask.

How much cash do you have in the bank?

Not how much you’re hoping to raise. Not how much you could borrow if things get tight. Actual cash, right now, in an account.