Skip to main content

4 Behaviors That Can Save or Destroy a Project

There are four behaviors (for sure out of many) that can easily destroy or save a project. Many scientific researches have been done on these dysfunctional behaviors and many new frameworks have been presented by gurus in management to deal with these dysfunctional behaviors, but still 99% of employees from top to bottom waste productivity and resources because of these behaviors. It is very interesting to know that many will not admit or accept it , despite all scientific researches and experiments, and will hate to read the rest of this blog ;) These dysfunctional behaviors are: Student Syndrome, No Early Work Transfers, Parkinson's Law, Polychronicity.

When was the best time to study for exam or write your homework when you were in school? or to put it in a better way, how many times have you prepared for your exam days/weeks/months before the exam? when did you start studying, after your teacher announced that there will be an exam in 2 weeks? From the same day or couple of days later, or maybe 2 days before the exam , or the entire night before exam?!

 This is Student Syndrome, Waiting until the last minute/hour/day to start a task that have been planned weeks before. The start of a project is as important and usually more important than its completion date. Many projects get delayed because they have started late! Project Owners are relax at the start of a project , there is no scenes of urgency or high volume of adrenalin, no management pressure; therefore they wait until the last minute to start a project. This is wrong, and projects can be saved and FINISH on-time, if projects Start on-time.

Have you ever watched a 4x100 Relay Race? Have you ever seen a runner in relay race runs faster than others and reaches his teammate, stands and rest and does not pass baton because he thinks he is far ahead of other competitors? of course not! what a silly question! In a 4x100 relay race, all team members run fast and do NOT delay passing baton to the next guy.  In projects, if you finish a work earlier than expected, you may not pass it to the next guy or you may pass it but not complete (although it is completed) and this is called No-Early-Work-Transfers! There are incentives for NOT reporting a complete task earlier than expected, such as management NOT reducing the task duration next time! The result is that, dependent tasks start late and therefore project gets delayed. Managers must be wise enough to avoid such dysfunctional behavior by providing a transparent environment and engaging team members in estimation process.

Although you may use buffer between dependent tasks to avoid No-Early-Task-Transfer or Student Syndrome, but here comes Parkinson's law: Work expands so as to fill the time available for its completion. If I give you 5 days to complete a task, In best case scenario you will complete the task in 5 days, although you may be able to finish the task in 2.5 days too!

What do many job descriptions have in common? Answer: Multitasking. Companies praise multitasking and encourage employees to do multitasking. But many management gurus have suggested that multitasking reduces productivity and quality of end result. This is our last dysfunctional behavior: Polychronicity. When tasks interrupt each other and one needs to deal with all of them at the same time, then things get messy. Although many claim that they are super woman and can handle multitasking, but if you watch them you will see NO sustainability and consistency in their work and end result.

Student Syndrome, No-Early-Work-Transfers, Parkinson's Law, Polychronicity are all human dysfunctional behavior and can be corrected by changing mind set and as result the culture of the organization from top-to-bottom. Project management methodologies and frameworks such as Critical Chain Method and Scrum deals with all of these dysfunctional behavior with simple techniques and tools.
Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

DAD Inception Phase Workshop Agenda

Disciplined Agile Delivery (DAD) realised the reality of the projects and introduced back phases to Agile community. Whoever works in a project based company, especially a project based company where projects are usually less than one year in length and each are for different clients, understands the reality of Agile in such environment. When you start working on a new project for a new client, it is essential to go through a phase that you get to know each other better, to understand the business purpose of the project, to understand the scope of the project, to know what are the high level architecture and what technologies are going to be used and who is the initial team, and if funding is available and also when things must be delivered and to whom.
In answering these questions you may need to meet with different people, run couple of workshops and brainstorming sessions. And this is called Inception Phase. As DAD is more like a goal oriented decision framework and not a prescrip…

Ingredients of Startup Failure

I have started and worked on several startups in the past 16 years. When I look back, I find the following patterns appearing again and again in every unsuccessful startup that I was involved in.

Here is the list of patterns, and they are not in order. I wrote them as they came to my mind:

Giving Up Soon: We gave up soon. Sometimes at the start of success we stopped. At one startup we started to make small amount of money after several months, and then we stopped! To be fair, we stopped, because the team collapsed, but anyway we stopped at the moment that money started to come in.Not Putting 100% focus: We did not put 100% effort into it.  For some of us it was the secondary job, and for some of us it was the last thing on the daily agenda!Not Hustling: We did not hustle.  Some of us took care of our comfort instead of hustling.  Not Passionate Enough: Some of us were not passionate about the problem we were trying to solve, or customers we were trying to serve, and the change we migh…