Project Assignment Contract and Checklist
Have you ever been assigned a task — big or little — and knew from the beginning that it would not be a pleasant experience and that it would never reach its full potential. I have lived in the software world for many years, and I have started to notice a few reasons why projects fail to live up to their potential. Here I list my pet peeves in receiving software engineering or data science project assignments at work.
The following should be a signed contract between an employee and his manager, or product manager, governing how all projects are handed off — but only if the business is concerned with project success and employee retention. Providing all of these, all of the time, may not seem realistic. However, if an organization completely ignores more than a few of them for very long, they will suffer as an organization.
Successful Projects Have…
Clear goals and objectives, and success criteria.
One or more measurable success metrics which each have a clear, simple, universally-understood mathematical relationship to the KPIs of the larger organization.
Clear priority relative to the employee’s other projects and an understanding of where that priority comes from, otherwise that priority won’t stick.
Allowance for the employee to make his own time estimate and end date (which are not the same thing), at the time of assignment and along the way before completion.
Allowance to explicitly reconcile and update goals (scope) and relative project priority with the due date when they are found to contradict each other.
A realistic and honest assessment about how much future maintenance will be required, otherwise it is not possible to know which best-practices to incorporate into the project.
Allowance as part of the time estimate to follow best practices commensurate with the anticipated lifespan of the project such as writing unit tests, documentation, etc.
A clear feeling that the project is doable for the employee and a good fit for his skill-set.
A level of difficulty that should ramp up at a reasonable pace after a new employee is on-boarded. Just because a new employee is a genius doesn’t mean she can do miracles before she is acclimatized to all the people, processes, systems, tools, data, conventions, expectations, and hidden assumptions and biases that her longer-time coworkers now take for granted and are no longer consciously aware of.
A lack of harsh judgment for an employee when the projects they are assigned assume skills and familiarity with data and systems that they have not been exposed to yet, regardless of how long the employee has been there.
Required resources and dependencies readily available for that employee.
An established and effective communication channel between employee and all other resources and stake holders.
Clear, motivating value within the business.
Reasons — communicated to the employee — for why that employee is the only one who can do this important project for the business. If he does not know this or if it is not true that he is uniquely valued by the company, he will not be motivated to perform the work.
Clear, motivating value for the employee’s interests and career development goals.
A scarcity of hidden political strings attached to the project and a lack of resentment between stake holders for what has gone on in the past. As soon as one group or employee decides that another group or employee is inferior and can be blamed for problems, the projects those people work on together are doomed to mediocrity.
Opportunity for low-risk and reliable feedback early and often, ideally direct from the end-user.
Unsuccessful Projects Have…
A manager who only measures project success by how fast the minimum work is completed. This leads to a real bias within a team toward creating technical debt. Managers need to learn how to measure project success in terms of quality in addition to quantity/speed.
A manager that fears that providing the above contract for all delegated projects is too much work. This manager will ultimately do more work in terms of artificially motivating and micromanaging the project.
A manager who does not delegate enough projects of the right size. This manager will be too busy to provide the right level of management in the form of the above contract.
A manager who cannot manage a project using higher-level objective metrics. This manager will require too much detail and spend too much time understanding details that he/she otherwise need not understand.
A manager that flatters the employee into taking on a projects in a bate-and-switch situation.
A manager that assigns projects before taking the time to fully architect a larger plan for the greater group. This manager will end up retracting projects too often.
A manager that imposes a timeline because “that’s just the way is has to be” without taking any input on doability from the employee, himself.
A manager that assigns a project to an employee without either the requisite skills or resources to help fill in the gaps. This manager will end up receiving either incomplete projects or projects that are more work to maintain or rewrite than it would have taken to make the correct assignment in the first place.
A manager who assigns multiple projects at the same time without thinking through the relative priorities. This manager will get lower-priority and lower-impact projects completed before high priority projects.
A manager who assigns too many projects at once and expects the employee to just get them all done at the same time. These projects have no confident timeline and suffer from the inefficiencies of repeated multi-tasking.
A team including manager and developers who don’t really understanding how to build what they plan to build, or an understanding of architecture or engineering best-practices. This team’s competitors will eat it for lunch because they will produce a much stronger project.
A manager who does not encourage the learning and implementation of best-practices. His team will get into the habit of making mistakes and not even realize it.
