Building a Simple Portfolio

How can a consultant present past work honestly when projects were small or confidential?

Start by showing the shape of the work rather than the size of the client. A short written summary of the problem, the decisions taken, and the result is often more useful than a logo wall. The Chartered Institute of Marketing frames professional practice around capability and responsible practice, and that framing helps here: a portfolio can be a record of competent work rather than a display of famous names (https://www.cim.co.uk/). If the project was small, describe the constraint. If the project was confidential, describe the method without the client name.

This is not a marketing trick. It is a writing problem, and clear writing solves it. The plain language guidance from Digital.gov says content should be written for its specific audience so that readers understand their obligations and benefits (https://www.plainlanguage.gov/). Your reader is a busy buyer asking one question: can this person do the work I need? Answer that question directly, without decoration and without vague claims.

What belongs in each case summary?

A useful case summary has four parts and fits on one page. First, a one line context: what kind of business, what kind of problem, what stage. Second, the constraint: the budget, the deadline, the missing data, the internal disagreement. Third, the work: what you actually did, in verbs, not adjectives. Fourth, the result: what changed, and how it was measured if it was measured at all.

If the project was confidential, replace the client name with a category, such as a regional manufacturer or a two person studio. Keep the industry general enough that the client cannot be identified but specific enough that the reader recognises the situation. If the work was small, say so. A three day engagement that fixed one bottleneck is a real story. A six figure transformation is not required for a portfolio to be useful.

How do you handle projects that were confidential?

Confidentiality is a constraint, not a reason to say nothing. You can describe the type of client, the problem, your role, the method, and the outcome in general terms, and you can leave out names, figures, and any detail that would allow identification. Many agreements permit describing work in aggregate terms, but the safe path is to ask. Send the client a short draft and ask whether it is acceptable. If they say no, write an anonymised version and say plainly that details are withheld at the client's request.

Do not invent composite clients that sound like real companies. A reader who discovers that the case study is fictional will question everything else. A short honest note is stronger than a polished fabrication. The CIM material on professional standards supports the same idea: credibility comes from consistent, responsible practice, not from presentation alone (https://www.cim.co.uk/).

How do you write about small projects without sounding thin?

Name the constraint. Small projects are often interesting because the constraint was tight. A two week budget, a single decision maker, a messy spreadsheet, a seasonal deadline. Describe what you chose not to do and why. That shows judgement, which is what a buyer is really assessing.

Also, group small projects. Three short engagements in the same sector can become one page called a pattern, with each project described in a few lines. This shows range and repetition without pretending that any single project was large. Keep each entry in the same order so the reader can compare them quickly.

One practical rule: write the summary in the past tense and in plain sentences. Plain language guidance exists precisely because clear content helps readers make sense of what is in front of them (https://www.plainlanguage.gov/). Avoid words like leverage, seamless, and robust unless you can define them in the same sentence.

Which format should you use?

A simple comparison helps. Choose one format and keep it consistent across every entry.

Format	Best for	Effort	Risk
One page written summary	Most consultants	Low	Can feel dry if you skip the constraint
Anonymised note	Confidential work	Low to medium	Reader may want a reference
Pattern page	Several small projects	Medium	Needs a clear through line
Redacted document	Technical work	Medium to high	Redaction errors are costly
Spoken walkthrough	First calls	Low	Leaves no written record

A decision checklist may be more useful than the table if you have only a few projects. Ask: can I name the client? If yes, can I name the problem and the result? If no, can I describe the method without identifying anyone? If not, can I write the lesson learned with no client detail at all? Each yes moves you to a usable entry. Each no means you keep the project out of the portfolio for now.

How should the portfolio be used in a first conversation?

Do not send the whole folder. Send one page that matches the reader's situation, and bring the rest to the call. Use the summary as a structure for the conversation: context, constraint, work, result. If the reader asks about a project you cannot discuss, say what you can say and offer to describe the method instead. Honesty about limits is often more persuasive than a perfect story.

Keep a short opening line ready, because the first sentence does most of the work. Describing what you do clearly is a skill worth practising before any meeting, and it pairs well with careful preparation for a first client meeting (see /pricing-position/describing-your-value/ and /client-work/first-client-meeting-questions/).

The portfolio is also a maintenance task, not a one time project. After each engagement, write the four part summary while the details are fresh, then store it in the same folder. A weekly review routine keeps this small habit alive and prevents a scramble before the next proposal (see /operations-basics/weekly-operations-review/).

What should you avoid?

Avoid vague claims about impact with no method behind them. Avoid confidential detail that could identify a client without permission. Avoid presenting a team's work as your own without saying what you did. Avoid long narrative case studies that bury the result on page three. And avoid describing a project as larger than it was, because the gap will surface in the first detailed conversation.

Keep the language plain, keep the entries short, and keep the constraint visible. A portfolio built this way is honest, usable, and easy to update. It will not impress everyone, but it will help the right reader decide whether to talk to you.