Manage expectations better by entering issues into an issue log (like the one in Vertabase project management software).
This will keep them from falling through the cracks.
You’ll be reminded of open issues by due date and be able to find issues by client before your next call with them.
Clients will feel better knowing that you are on top of issues affecting their projects -particularly issues that they may have brought up. You’ll know about them and be able to set expectations based on the latest status.
Even if the issues were mentioned verbally, in a meeting or in the hall, enter them into a centralized issue log. Though an issue can lay low, remaining unmentioned for weeks, it can come up and bite you sooner or later.
The shorter the communication, the more careful you have to be.
That’s why many successful politicians cultivate the ability to talk for hours on end and not be pinned down to one particular point.
Email, text messages and twitter can be dangerous ground for miscommunication. If you are using those tools to speak to your project’s client or sponsors, you have to be doubly careful. Those communications form the client or sponsor’s expectations.
Communications set Expectations.
Misinterpretation and unmet expectations can easily happen, leading to a decline in your relationship with the client or sponsor.
To effectively use those tools for project management, you have to be certain of the parameters and flexibility around the relationship. The relationship should exist well before-hand and have room for the ups and downs mis-communication can bring.
Otherwise, make sure you use the phone more or even have face to face meetings. This gives you room to answer and ask questions, to read your client’s expressions and better understand the expectations set by your communication. Plus, it’s a great way to build a long lasting, personal relationship.
A software developer deals with unique situations almost every day.
Every project, every bug fix, every issue has its own unique challenges and one of a kind circumstances.
Even if the functionality has been built before in other systems or is available on other pieces of software, implementing it on a specific system or integrating it with existing code has its own set of challenges. A developer really does work on “projects” in the sense that they work on unique endeavors that have some degree of uncertainty and risk of failure.
As far as the other side of the formal definition of a project, having a defined start and end date, that’s often a matter of controlling scope creep or change requests
Because developers are working on projects there is no single body of knowledge they can master to have answers to questions right off the bat.
When you ask a doctor about a pain in your side, there is a well documented set of potential answers and a huge body of research on the most probable answer based on other data points/symptoms reported. They can usually give you an answer off the cuff. And if not, there are prescribed recommend tests to further find the answer. This isn’t the case with a software developer.
A software developer is not a doctor. No two bodies of code are the same.
Next time you ask a developer for an answer or an estimate, don’t surprised if they need time to come up with the answer. Or, if the answer they give is inaccurate or if the estimate is off.
The same is true of designers and creative knowledge workers.
Emotions can propel you. Emotions can bog you down.
Emotions hang on a framework of expectations.
Expectations hang on the plans we carry with us. Whether in our heads, in software or on paper.
Understand plans (and how they change over time) and you can achieve growth.
This applies to organizations and to individuals.
