Management

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. ...

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 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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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 ...

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. ...

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. ...

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. ...

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. ...

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 ...

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. ...

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. ...

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. ...

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. ...

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.

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.

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.

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.

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.

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.

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. ...

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.

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. ...

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 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. ...

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. ...

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.

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. ...

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. ...