What is Project Management, and (perhaps, more importantly) what it isn’t?

Introduction

There is a lot of misinformation floating around about project management. Some of it is because many people assume they know what it is, or what it means (and they really don’t). And some of it is because people have been told or taught something that is incorrect or was out of context.

The thing is, understanding what a project is, along with its dynamics will make managing a project that much easier. That said, more formally managing a project properly is no guarantee of project success, but it does hugely increase the chances of success. Of course, the converse is true too. Mismanaging a project (of anything that is relatively complex) will almost certainly derail it.

The purpose of this post is to introduce you to what project management really is, and the benefits that come with understanding and following a methodology. It’s to get you to think a bit about your own projects and start to see why your project might feel like it’s trying to herd cats.

There are many arguments about whether project management is an art or science. Project management theory that’s covered in and outside of the numerous methodologies convinces me it’s a science. However, I also believe juggling those theories is an art, and practice makes perfect (well, maybe not perfect, but you definitely get better at it the more you do it).

So, who am I to tell you this stuff? Well, for almost 20 years I have been a certified, full-time professional Technical Project Manager. I’m a certified PRINCE2 Practitioner and a certified ScrumMaster. I have managed numerous $multi-million projects including several large 24×7 data centre migrations/relocations, and numerous large software developments (including building a financially sensitive news dissemination software product to rival the London Stock Exchange’s version).

Project Management is a huge (and sometimes divisive) subject. This article is really only going to touch the surface of the subject. It will introduce you to some core principles behind project management and some of its common terms. This is also not meant to be prescriptive. There are many project management approaches/methodologies out there, but most all deal with the same elements, just in differing ways.

There is some practical advice below, but it’s more important to be open to the principles and considerations being shown rather than the execution at this stage.

What is a project, and why do they often fail?

So, let’s start with defining what makes a project a project. This definition is the distilled truth for any project at all regardless of industry, sector or size.

There are a few definitions floating around classifying what a project is. And it’s actually a lot simpler than many people think. For something to be classed as a project it MUST have (at a minimum) these two qualities:

• It must have an end date
• It must be a discrete piece of work

And that’s it. No, seriously, that really is it.

If there is no end date, it simply ain’t a project – it’s just some work to be done, or a collection of tasks. It’s the time-bound element that makes any work to be done into a project.

However, to be a project the work to be done must also be a discrete bit of work, and by that, I mean the outcomes and/or deliverables are properly defined and agreed upon between the project manager and the requestor/client. In other words, there are a finite number of well-defined “things” to be delivered. Anything new or outside of that definition is “out of scope”.

Now, that’s not to say that the definition of what’s to be delivered cannot be changed. It absolutely can (e.g. introducing something new or outside the current scope), but a process should be followed to introduce changes properly so that both sides are clear on the impact of doing those changes to the project (usually related to timescales and costs). We’ll touch on that when we talk about managing project changes a bit later.

So, those two things together form a project to deliver those outcomes/deliverables by an agreed date (or possibly a set of dates if there are multiple deliverables). Another way to think of this is, without those two things clearly stated, how will know when you’re done?

Work classed as a “project” with no clear intended end date and objectives (or goals, if you like) is destined to be one of those fabled eternal projects; a project that simply won’t die. One massive way to avoid that is as simple as ensuring your project really is a project!

There are usually other aspects important to a project, such as cost and quality (we’ll get to those a bit later), but they are not, in themselves, what makes a piece of work a project.

Now we know what a project is, you can start to see why it is that so many projects fail?

There are numerous other reasons for failure but getting those two things right at the start will help to avoid many of them.

The key point takeaway here is it’s utterly imperative that both sides are in crystal-clear agreement what the project will deliver and by when, and for that to be documented and signed off by both parties. Time spent ensuring this is done upfront (as far as can be) will save time, cost and heartache down the line.

The Project Brief

There are numerous project management methodologies out in the ether, e.g. PRINCE2, Agile, RUP etc. and they each suggest various ways of starting to document what the project is.

Generally, they all suggest starting with something like a Project Brief. The main sections a brief should cover include things like:

• Project Definition – includes which bits might be purchased, outsourced, built in-house, desired outcome(s). Also, the project’s objectives and scope. Also any anticipated dates.
• Initial Business Case – the reasons and costs for doing this, and how it will doing this project benefit the business (ROI, more leads etc).
• Initial Deliverable Specifications – high-level initial specifications of the various deliverables.

Also, notice the word scope in the first point. Really think about that one and ensure the client/project sponsor is clear on that. For example, if they’ve asked you to change some of their sites, make sure it’s clear exactly what sites this project will cover by stating the scope. You can also include a “not in scope” section to be utterly clear what you won’t be doing (e.g. we will not be responsible for writing any content for the sites).

These sections don’t need to necessarily be named that in any proposal or brief you create. As long as those things are covered. The purpose of the brief is to ensure both you and the client are on the same page before you spend too much time and effort going down any rabbit holes. This should go back and forth a couple of times to get it right. And even then, it’s only an estimate. And an estimate is just that, an estimate. It’s not a categorical commitment (because that is generally impossible to truly guarantee and therefore risky on any half complex project).

One thing I’ve learned, especially around timescales and costs in a proposal or brief. Be really clear to the client/project sponsor that those values (and again later on when they become more refined after detailed planning) are on an “all things being equal” basis. That is, there will always be assumptions and things outside of your control. For example, you know your external graphic designer can usually turn around a logo design in a week. But until you engage them for this piece of work you can’t guarantee that. They may have just gone on holiday or are ill. You want to minimise being on the hook for those wherever possible. You do that by being totally upfront with the client. Not necessarily with specifics, but just offer your proposal in a way that allows for variance.

For example:

“Hi Bill,

Right now, the estimated costs look like $xxx, and we plan to have it all completed by the end of February.

Whilst we don’t anticipate this will change, it is possible that there are unforeseen circumstances that might affect elements outside of our control.

Should this occur we will alert you immediately and seek your approval for any remediation before continuing.”

And should that happen, do just that. Refine your estimate and go back to the client/project sponsor seeking approval, making sure any decision is recorded in writing somewhere.

Once this is well nailed down you can then start your detailed planning.

What is a Gantt chart (and why it’s NOT a project plan)

First off – and let me scream this from the roof-tops – a Gantt chart is NOT a project plan!

The number of times I’m given a Gantt chart when I ask to see a project’s plan would seriously make your head spin. If you’ve not come across Gantt charts before, here’s an example.

In essence, a Gantt chart is a pictorial representation of a project’s tasks and when those tasks are scheduled to happen. They can also show other things like task progress, who’s assigned to a task, whether a task is dependent on one or more other tasks etc., and overall, it is an incredibly useful scheduling tool.

The point here is that a Gantt chart a project schedule; it’s NOT a project plan.

To be clear, a project’s schedule is a hugely important element in any project plan, but it forms only part of the project plan, as we’ll see shortly.

So, what makes a project plan?

As you’ve gathered already, the schedule forms part of the project plan. Gantt charts are commonly used to illustrate this within a project plan. They are usually “rolled-up” or collapsed in the plan, i.e. only the main summary tasks are shown. This is simply because a high-level view in the plan is usually enough (the fully expanded version is kept available and regularly updated as the project progresses). Now, you don’t need to use a Gantt chart to show the schedule. It’s entirely up to you; a table of steps with dates may well suffice for you.

So, what else is usually in a project plan? Well, each project management methodology prescribes its own best practice. My own preference is basing the project plan around PRINCE2’s Project Initiation Document or PID (often pronounced as it looks – “a pid”). Now, I’m not suggesting you go all-in with a PID. It’s pretty much a bible for your entire project, as such it’s a pretty intensive document if used as intended. My suggestion, depending on the project’s size, is to steal just the project plan section of the PID. If the project is a large project within a large organisation then a full PID will almost certainly be required.

Before getting to complete a project plan the Project Brief will have been circulated and agreed with the client/sponsor. You should then have moved onto a detailed discovery/requirements gathering exercise. This should have included involvement with the client (and/or Business Analysts on large projects), but may also have included external resources like possible suppliers, designers etc. Before getting to the main project plan, the kind of details you should have acquired are:

• Gathered all the detailed requirements
• Understood the project’s resourcing needs (who’s needed to bring the project to fruition)
• Understood any costs (your costs, external costs, license costs etc, planned profit)
• Understood any dependencies (i.e. the order stuff needs to be done in)
• Detailed specifications for any deliverables (blueprints of what you’ll deliver)
• Scheduling tasks (determining all the tasks to bring the project to fruition, how long they will each take, who’s doing it etc)

All those things will end up going into your project plan. It’s worth noting that for very big projects the plan isn’t necessarily a single document. In some cases, it can act as a big Table of Contents that simply reference separately detailed documents.

Regardless, the usual sections you’d expect to see in a project plan are:

• Project Definition
  • A description of the project
  • Any pre-requisites or assumptions to be factored in
  • Any external dependencies
  • The project’s schedule (e.g. Gantt)
  • Any constraints to be aware of
  • Any interfaces to be aware of/prepared for (e.g. does the site need to integrate with something external?)
• Stages – a breakdown of all your planned stages (PRINCE2 uses the word “stage”, but essentially it means “phase”), each covering:
  • A description outlining the purpose of each stage
  • A list of the deliverables each stage will produce (and by whom)
  • A list of the resources necessary for each stage to be a success
• Milestones – a table (derived from your overall schedule) of the key milestones. A milestone essentially marks an important achievement during the project. It has no duration as it is not a task as such – it just a great way to easily monitor project progress. Examples could be, Client signed-off the design, website launch etc.
• Financial Summary – a detailed breakdown of your costs to complete this project (and potential profit if you want to show it internally).
• Communication Plan – an agreed list of who gets what information or updates, and the frequency.
• Deliverable Specifications – detailed specifications for each separate deliverable. They should cover these areas:
  • Purpose of the deliverable – what’s its reason for being produced?
  • Derivation – what information or “ingredients” will be needed to build it? For example, a design document will need information pulled from interviews with the client, maybe the web developer etc.
  • Composition – detailed of what will be delivered (this can include images), e.g. if it’s a design document, then the sections it will address
  • Allocated To – who will deliver this
  • Format & Presentation – how it will be manifest itself? For example, if a website can state it will be a WordPress site available over https, or if it’s a design document it may be as a PowerPoint presentation or PDF

Once you have an initial version of the plan, you may need to go back to the client/sponsor with it and/or a revised Project Brief for approval, especially if your detailed planning has had an impact on the costs and what you can and can’t do.

One final point on the project plan. It’s a living, breathing document that should be continuously reviewed and updated as the project progresses. Anything that affects deliverables, timescales or costs should always be fed back to the client for a decision or agreement. This is just like before when providing an estimate in the form of a proposal or brief. Your plan is just that – it’s what you plan to do. Nothing is really set in stone; “man plans and God laughs”, right?

You may be the best project manager on the planet, but you’re not a magician, and shit, unfortunately, often happens. Regularly reminding the client/sponsor of that (subtly or otherwise) is rarely a bad thing. This is one of the ways (not always pleasant, for sure) that you control a project and keep it on track. Good, regular communication is key, whether good or bad news, your clients/sponsors will see (and will appreciate) that you are in control. However, bear in mind the worst case may be getting agreement to terminate a project if it is no longer viable.

Change Management (avoiding Scope Creep)

This brings us nicely onto Change Management. Whenever something needs to be changed on a project then it MUST follow a change management process (and not necessarily one that has to be onerous). More importantly, your client/sponsor must know at the outset that such a process exists and will be followed, so make it clear in your brief and plan. It’s the only sure-fire way to majorly minimise the dreaded scope creep.

If you’ve not heard that term before, scope creep is when a project veers away from an agreed set of deliverables, meaning you are now providing more than was originally agreed – usually for no extra budget or time.

This sort of thing usually starts with just one or two small or insignificant client/sponsor requests, “Oh, can you just add this bit to that”. Once you say yes (because you’re just being helpful and understanding, right?), you’ll have created a dangerous precedent that will likely get abused. You may well feel you can’t say no now to other future requests, and the next thing you know is that the project’s scope has increased, quite likely to a point that it’s no longer viable within the originally agreed parameters. Not good.

So, how do you address this?

Every request should follow this sort of process:

Formally document the request – ideally, get the client/sponsor to do this by telling them they need to raise a Change Request (or CR). Maybe set up a form for this on your website/intranet. Have fields asking for the client’s details and details of the change requested. I actually have this set up on my website for my smaller clients (in a portal) and it auto-creates a change log entry, plus a ticket in my ticketing system.

Here’s a sample CR form:

Log the CR – for every project I have a Change Log that records the CR form entries. I also have a column whether the CR is accepted by the client and on what date. You can potentially automate this if you’re proficient with something like Zapier or Integromat. For me this is also viewable by the client in their portal. Here’s an example log:

They can click on the unique CR number to see the full entry details of the change – note, all the values may change as the change goes from assessment to approval (or not).

Assess the change – your focus here is really an impact analysis, i.e. what’s the impact of doing this change?

• First, clarify the request – go back and forth with the client/sponsor to ensure you are clear on the requirement – ensure it is in writing
• What’s the impact on what’s already been done – will stuff need to be reworked or scrapped?
• How much time/effort will introducing the change take?
• Will it affect the end date?
• What are the cost implications? Unless it’s a supremely simple request (such as change a line of text) there’ll likely be a cost impact.

Communicate the result – communicate the assessment back to the client. For example:

Dear Bill,

We have assessed CR-[XXX], which is to:

[list the finally agreed request details]

We can absolutely do that for you by [date] / [or not]. To do so, please be aware that the overall project end date will be delayed by 2 weeks, and will add $475 to the overall project costs.

Please reply, Accepting or Declining (based on the above) as to whether we should proceed with this change or not. If you decline, we will simply carry on as we were following the last project brief.

Once the client’s decision has been made (one way, or the other), the CR log entry may now look like this:

Update the Project Brief and Project Plan – if the change is accepted then update the brief to reflect the new timescale and costs, as well as the Change details (add a new section to the brief listing any approved changes). Send the updated version to the client. Also, update your project plan too.

Update the Change Log with the result – whether accepted or declined, and the date of the decision.

If you follow that process, you will avoid (or at least hugely minimise) scope creep. It will also minimise the number of requests you’ll likely get.

The three forces you need to know about that affect a project.

It’s really important you understand this; not least of all it will greatly help you tell your client/sponsor why something they’re asking for is sometimes ridiculous (albeit in a nicer way). There are just three forces that constrain a project:

• Time (available to deliver the project)
• Cost (amount of money or resources available to the project)
• Quality (a slight misnomer –whilst the quality of a deliverable is a factor here, it’s also about the features a deliverable will have and those features’ acceptance criteria)

This is often shown in a “Scope” or “Quality” triangle – and really illustrates possible the trade-offs when managing a project.

In most cases one of these forces is fixed, for example, it has a drop-dead date or a maximum budget. This means one (or both) of the other two forces can be varied to accommodate that the third force is fixed. That may sound like gobbledegook, so let me explain.

Let’s say you have a project to build an e-commerce website. Your high-level brief indicates:

• A 4-page website: Home, About, Contact, and Shop that all load sub-2 seconds (Quality)
• Cost $9,000 (Cost)
• Launch in three months (Time)

Your client/sponsor then says that three months is too long – it needs to be a drop-dead duration of two months – in other words fixing the Time force.

In order to fulfil the project with that time frame constraint, one or both of the other forces in your brief MUST change to accommodate that.

You can reduce the Quality of the final product; maybe drop the e-commerce Shop part and add that back in a later project.

Or you could possibly leave the Quality as is, and increase the cost to $12,000 to pay extra resources to work on the site to ensure it’s all done in two months?

Or maybe a combination of the two.

Now, let’s say the client is fine with the original brief, but only has $6,000 in their budget after all (so fixing Cost instead of Time).

In that case, you can use fewer resources, saving cost, but the project will take longer (maybe 4 months). Or you might drop a page or two, or perhaps make the shop smaller. Or, again a combination of the two.

The thing is, when a constraint is applied, the other forces must take the strain.

It gets more interesting if your client fixes two of the forces! What if they say it must be $6,000 and take only two months? Well, it’s clear that if the Cost is fixed and the Time is fixed, then the Quality must suffer – in other words, the scope of what will be delivered must be reduced. This applies with any two forces; the third must always adjust to accommodate.

And because of this, you can only ever fix a maximum of two forces. If a client needs all 3 fixed then that’s a huge red flag, and you need to explain why that’s generally unacceptable (read impossible). I say generally only because if you’re fortunate that all forces available to you are massive at the outset, then it is possible to deliver that project. This is rarely the case though.

This is an incredibly important principle to understand when planning a project and especially when discussing the plan with a client. In particular, when they try to insist all three aspects are fixed. As you can see, if you unwittingly agree to that you are more than likely setting yourself up to fail. So beware.

Agile vs. Waterfall?

As stated earlier, there are numerous methodologies out there for managing projects. Generally speaking, they all fall into one of two camps: Agile or Waterfall.

Many organisations are in fact a hybrid and are Agile-ish (as opposed to truly Agile). And, personally, I am totally fine with that.

But it does irk me when people flout they are Agile, and yet it’s clear they do not know really know what that means (maybe just sounding knowledgeable with a current buzzword). It’s a little bit like thinking a Gantt chart is a project plan (when it bloody well isn’t… and breathe). I often get people telling me they are Agile – and when I ask how are they Agile, they tell me they use Trello or Plutio’s “Kanban” style boards to manage tasks.

Er, that’s not Agile – not in the least. That’s simply another example of using a tool (albeit one often used when Agile), and totally missing what Agile is all about…

Okay, so what’s the deal? The best way is to show the two main project management methodologies side-by-side.

Waterfall

Waterfall is the more traditional (and older) style of the two and can be used for any type of project, e.g. construction, software development etc. It gets its name from how projects managed this way look when shown on a Gantt chart. If you look at the example Gantt chart earlier, you’ll see that the progress bars look a little like 2 waterfalls. This is because waterfall projects usually have tasks that (very generally speaking) follow on from each other sequentially. There is nothing wrong with this approach, and for most types of project, this is the more logical and appropriate way of managing them.

Methodologies that generally use waterfall include PRINCE2, CAPM, PMI etc

The major downside to the traditional waterfall approach is when projects are long and complex, e.g. 6 months plus. Scheduling tasks for the next few weeks is fine. However, scheduling tasks to occur further into the future (e.g. 6 months plus) is fraught with danger. So much can happen between now and then that the likelihood those tasks remain valid at that time is very low. This is because any issues that occur in the next week or so can completely derail the tasks planned in 6 months’ time. And so you are continually making big changes to later on in the schedule, simply because of little tweaks to tasks occurring now.

The other issue with planning that far ahead is that by the time you deliver (even if it’s exactly what the client wanted initially), their business model may have changed and what you’ve produced is no longer any use or relevant to the client!

The final main downside is that the client/sponsor doesn’t usually get to see anything material until near the end of the project. And particularly for software development projects that’s a big drawback.

The PRINCE2 methodology (of which I am a big fan), which is usually waterfall (though it can adapt very well to work with Agile projects too, by the way), is all too aware of these problems. To deal with them PRINCE2 has some very clever principles and processes. One thing, PRINCE2 insists that every project is broken into stages, and there must be a minimum of two stages in any project; an initiation stage and one or more execution stages.

The initiation stage (at a very high level) is where all the initial feasibility and planning is done to the point where you are able to complete a fully formed initial PID. In that PID you will indicate how many stages the remainder of the project will be broken up into. You might show this inside the PID as a Gantt chart just marking out the stages, e.g. the first execution stage (say, agree the website design) will start in 2 weeks’ time and last 4 weeks, the next stage (maybe build a prototype) will follow on after and last 2 weeks. And so on until a stage that launches the project and closes down the project.

The key thing here is that PRINCE2 only expects detailed planning for the next stage only. The remaining stages are just placeholders until you get near to reaching them. PRINCE2 has a process that is triggered at each stage boundary (i.e. at the point one stage ends and the next is ready to start) which basically does this:

• Pause to re-review the project against the business case, i.e. is the end goal still valid and should this project carry on anyway?
• If not, the project is terminated.
• If it should carry on then fully plan out the next stage.

What this does is two-fold:

1. It ensures that say, a 2-year project, will more likely be a success because it is continuously reviewed against the business case, confirming what will be delivered continues to be relevant (or not).
2. The project only plans out in detail the very next stage, meaning you do not waste time planning things that are too far out to be realistic.

This makes PRINCE2 very versatile whether for software development or not. However, for many in software development, it still wasn’t flexible enough. So Agile was born…

Agile

Agile methodologies (e.g. Scrum, Kanban, Lean etc) came about specifically for software development projects. Instead of a linear, sequential approach used in waterfall it favours a more incremental and iterative approach.

The premise is you have an idea for a software product, e.g. a WhatsApp competitor. You then brainstorm all its features and attributes, essentially its requirements – but in Agile-speak they are called User Stories.

A big change or update, let’s say a whole UI change, is known as an Epic. And that will be broken down into many User Stories.

These stories get listed in a Product Backlog. The Product Owner (or client/sponsor) continuously re-orders and refines this backlog whenever they want (the most important stories being moved to the top). They can move stuff, add stuff, and delete stuff. This is one reason where Agile’s reputation for flexibility comes from. The client can chop and change their requirements and order of fulfilment at any time.

Coupled with that is the concept of a sprint. A sprint is a short burst of development and testing activity, at the end of which something gets deployed (usually to a staging area where the client can actually see it). Each organisation usually chooses a sprint length and then sticks with it. These are usually one or two weeks in length, though sometimes as long as four weeks or more.

At first glance, this may sound a bit insane, but read on…

The final part of the equation is the development team. They are empowered and self-managing. Towards the end of a sprint, the next top story candidates in the Product Backlog are reviewed, spec’d, and sized by development. And if agreed with the Product Owner or client, those stories are added to the Sprint Backlog; these will be the stories developed in the next sprint.

Of course, these items will vary in effort and are often too big for a sprint, so they need to be split out into smaller pieces of work. Once agreed, the Sprint Backlog then gets frozen and the sprint starts with the developers managing themselves to achieve the goals of the sprint. And then it’s a case of rinse and repeat in future sprints.

The main benefits are that the Product Owner or client gets to see continuous results (in staging) and can chop and change the features and product’s direction very easily. Periodically it will get agreed when to update the live product with that in staging. The Product Owner’s only limitation is they cannot change a sprint once it’s been frozen. However, this still gives massive flexibility over waterfall as they may only have to wait a week to change stuff, i.e. in the next sprint.

You may have noticed there’s no mention of an end date. So how is this a project?

Earlier, Epics were mentioned – these will have a target end date, so from a planning perspective you can consider each Epic to be a project in its own right. Furthermore, you can also consider the sprints as being stages in that project. It’s for that reason that PRINCE2 can still be effectively used to govern overall project management in an Agile environment.

Given the quick turnaround and throughput of stories from backlog to being “done”, visual tools like Kanban boards (see example below) help to see what task is where by using task boards like those found in Trello or Plutio. However, just using boards to track tasks doesn’t mean you’re Agile. Using backlogs in conjunction with sprints does.

There are some great tools out there, but you should only look for tools that help you manage the approach or methodology you’re following.

I also don’t believe (as yet) there is a one-stop-shop tool or suite that will do it all (happy to be shown otherwise, believe me – although ClickUp looks like it might be pretty close, I’ve not looked at it in any detail as yet). So unless you find something that meets all your requirements you’re better to pick specific tools for specific jobs.

For tracking tasks, Trello or Plutio work well visually, but I don’t believe you can show dependencies between tasks in those (but don’t quote me on that).

So, to conclude this comparison. Agile is great but specifically when it comes to software development projects. For me creating something like a website and website development is not strictly software development, and waterfall makes much more sense. Sure, if you are creating a website component or service from scratch, i.e. actual software development, then, by all means, run that part as Agile if it makes sense to. You can still govern it inside a parallel waterfall stage, or just leave it as separate side Epic.

Project Management Tools

This final section discusses some of the tools out there. As suggested earlier, your approach to managing projects should dictate the tools you use, not the other way around.

So, if you’re mostly waterfall you’ll likely want something to aid scheduling and to produce solid Gantt charts. In my opinion, nothing out there touches Microsoft Project for that (Note: ClickUp does manage basic dependencies, which may be good enough, but Microsoft Project has many more dependency options).

Another reason for Microsoft Project is that it covers so many factors that can be used to alter how the scheduling will be done. For example, it will show when a resource is overloaded. It can also factor in team members own availability calendars. It can even do bulk resource levelling, i.e. when resources are overloaded, re-schedule everybody’s tasks to when they have the bandwidth to do it. It can also manage resources in pools and track against them across multiple projects. However, the downside is that because it does so much (it very much is the professional project manager’s go-to tool) it is a beast to get to grips with and fully learn properly.

Microsoft Project also has a team/cloud version (pricey), otherwise, you can just use the local desktop app version.

Other common tools include Asana, Scoro, Basecamp, Jira – some are specifically software development/Agile focused, and some are not. Again, focus on what you want help managing, rather than fitting your approach to a tool.

Summary

So, there you have it, a brief (believe it or not) introduction into what project management really is, and some of the things you should consider.

Probably the biggest takeaway should be communication. It’s almost impossible to provide too much communication. The old adage of “no news is good news” is absolutely the wrong attitude if you want to do best by your client/sponsor. It may not always be good news, but your client will appreciate being told it sooner rather than later (even if it doesn’t feel like it). Really.

Finally, unless you’re a project management professional that must follow the letter of the law, it’s okay to be pragmatic too. I’m a true believer in “horses for courses”. In other words, do what’s right, rather than do things for the sake of doing them. If your client/sponsor is the one being overly prescriptive, try to educate. Everything you do should have value; if everyone is fine with a weekly update, for example, then don’t waste your time doing a daily update.

Generally speaking, the bigger the project, the more of this stuff you ought to include. If it’s a very small project you can likely ignore large chunks of it (although I don’t actually recommend that).

I hope you have found this post helpful. Happy planning!

Planning a project?

SEND ME MY FREE DOCUMENT TEMPLATES