Project management is about communications, scope control, and managing the client’s (or management’s) expectations. I don’t mean to suggest that there aren’t other things to think about, but if you can nail those three things, the others will likely fall into place. That’s particularly true if you have a trusted methodology in place for managing a gazillion project details.
While managing software projects is not all that different from managing other projects, there are some unique considerations to take into account. Here are five tips for managing software projects.
Most of your clients are not geeks.
I experienced this first hand on a recent project I managed for a software developer. The project was a website for one of their clients. On our end, the website was ready to be taken live, but there was one problem: their client was holding up the process.
We had told the client a number of times that we needed to know who controls the DNS and how to contact them. Said differently, we told them we needed access to the DNS server setup. We couldn’t provide a working URL until the DNS had been assigned and pointed to our new landing page. We were making no progress, yet the client kept asking for the new URL.
Finally, a light bulb went off in my head and I realized that the client probably didn’t know what a DNS was. Once I rephrased our need without using that term, we could make progress. My problem, as a non-technical project manager, was to get my team to speak to me in real language that makes sense.
To control scope, we need to define it.
When I built Smart Projex, I was a boot-strapping entrepreneur who was happy to spend hours helping to clarify exactly what I wanted before the first line of code was written. When someone was willing to explain geek-speak and not charge me, I was taking notes. Not all clients are so eager, or have the time to work with you on clarifying scope.
The need to define scope is not unique to software projects. All projects need scope control. But not all projects require the client to learn a new language. To fully define the scope on a technology project, the client needs to learn a little geek-speak. For example, if you have been engaged to build a web application for a brilliant new idea, is your client going to be involved in deciding which platform or coding languages are used, or how much security is built into the tool? If you are building a database, is your client going to define the fields and their attributes?
Software developers are typically hired because of their expertise in an area that can be a foreign language to the client. Defining scope means to first understand what the client wants and needs and then, explaining it in language that the client understands. There will likely be iterations in this process as every email exchange or phone conversation can open up a new set of “what ifs.”
Defining scope is like eating an artichoke. Until you reach the heart, you’re just nibbling in a circle. I’ve lost track of the number of times that I’ve gone back and forth with a client over what they wanted something to look like, only to realize later that the final product looked great, but didn’t really meet their needs. When you are defining scope it is essential that you don’t get so bogged down in the details of how to do something, or what it looks like, that you forget the objective. This may mean uncovering motivations that even your client hasn’t yet identified.
Defining scope is like eating an artichoke. Click To Tweet
Managing client expectations means knowing what they are.
Every client is different, and understanding the personality differences for all of the key people in one organization takes time. Understanding which clients are budget conscious, have stringent approval processes, want weekly updates (or not), or are too busy to test your software changes in a timely fashion is important. Does your project software provide fields for cataloging this information?
You will likely be working with multiple clients, all of which have their preferred communication methods. Some clients may not respect the boundaries that you try to put in place so that your developers have long blocks of uninterrupted time in order to write code. Managing expectations sometimes means saying no.
Managing expectations sometimes means saying no. Click To Tweet
Most clients expect you to contain costs.
Even when a client tells you that quality or schedule is their most important consideration, don’t forget about the budget. Getting the work authorized by the client may seem like a no brainer but different clients will have different cost authorization thresholds. These thresholds can give you some pretty good insights into the cost sensitivity of the client.
Most clients do not have a blank check. Ask your client how they want their budget data reported. Consider the size of the project and what makes sense. Some might prefer a bottom-line number, while other clients and other projects might dictate a report that shows the cost of each deliverable.
Just reporting on costs is the first step. The next step is to keep your eyes open for ways to save your client money. You may want to simply ruminate on ideas, in case your project starts to run over and you need to find a cost savings to offset the overrun. OR, depending on the project, you may decide that a piece of the scope or the plan for one of the deliverables makes no sense. In such a case, you may recommend a shortcut.
Your project data may not all be in the same tool.
This can be true of many projects, across many industries. Yet the software world has an added complication – bugs!
Software developers often work in an environment where they are building new software, building enhancements to existing software, fixing bugs, providing estimates, and answering questions that require research or thought. These very different tasks require different management strategies. Using a bug-tracking tool for large projects will completely skew your client service analytics.
Add to that the fact that many software developers are freelancers working for multiple companies, with multiple project software tools. Before you know it, you can wind up with some tasks in a ticket tracking software tool, and other tasks in various other project tools. Add to that the need to remember that you’re supposed to pick up the milk on your way home, and suddenly a piece of paper on your desk feels like the easiest way to track your to-do items.
Managing software projects is not all that different from managing other projects, as long as you understand the language barrier. Do you need help? Check out our coaching packages here.
