Modern businesses recognise the importance of driving innovation and continuous improvement through team-based projects. This does not mean, however, that organisations have gotten smarter at selecting the correct type of projects. In this cheat sheet, I list four mistakes that are commonly made, but easy to avoid.
Selecting problems that no one really cares about
It’s tragic, but teams, departments and business units still choose projects that nobody cares much about. Often, it’s because the scope of the perceived problem appears too minute, or the potential project might not be critical to business objectives. Whatever the case might be, a neglected project suffers from corporate inattention, and the team involved in it will wilt.
Selecting a solution to implement rather than a problem to investigate
Nothing alarms me more than facilitating a team of employees who, instead of investigating the root causes of a problem, have already determined the solution. I find this fairly typical in projects led either by newly-minted IT Professionals or employees who have grown too close to the process.
In this instance, a team of managers working at a college admissions office might describe their project with an ambitious title like: Automate the fee payment process with an online application. The title is already a warning sign that danger lurks ahead. By enlisting words like automate and online application, the team has already made up its mind on the solution. No problem was investigated.
There are very little exceptions to the rule. Projects should always be described from a process standpoint. The team from the college admissions office would do their project far greater justice by describing it as an effort to Reduce the turnaround time for students paying school fees instead.
Selecting a process that is in transition
Businesses nowadays face lots of turbulent change, either in technology or in regulatory compliance. Inviting teams to improve a process or function that is going to be changed soon will only waste company resources. There is no point investigating a manual leave application process, for example, when some other team is independently migrating it to an Enterprise Resource Planning (ERP) system. The work being done by the first team would quickly become redundant.
Selecting a system to study, rather than a process
A common error committed by new teams is to be too ambitious for their own good. Instead of breaking a project up into manageable bits with short durations and clear targets, they attempt to take on an entire system or framework of business functions at once. Leave such high-order improvements to management teams or portfolio managers. Ongoing work improvement teams have a better chance of success if they focus on a smaller process to study and subsequently improve. Realistic timelines and targets make for more motivated teams.
Are there particular types of projects that you consistently avoid? Do share by commenting on this post!