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.

Comments

Popular posts from this blog

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to Kanban From High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important.  Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate.  Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while,

Stay Fitter

1st edition of Fit for Purpose: How Modern Businesses Find, Satisfy, and Keep Customers from David J Anderson and Alexei Zheglov was published in Nov 2017. They wrote the first edition in 7 weeks during summer 2017. I had a chance to provide feedback to them as they were writing and editing their chapters. The book basically talks about what a product and service is made up of, how customers measure the product or service and what metrics company managers must apply at different levels to be always fit for customer purpose (the Why's of the customer). If I want to summarise the book in one statement, it would be like: Align your business to how your customers measure your product and service. When I was reading the chapters, four guys came to my mind: Peter Drucker, Jack Trout, Eliyahu M. Goldratt and Clayton Christenson. The book reminded me of Peter Drucker; because he once made a profound observation that has been forgotten by many, his observation goes like this: "B

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*2 And 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 thei