Movies and Project Management

Well making a movie is no doubt a project and needs careful management to make a good movie. But let us look at movies and project in a different angle.

Time for the background. The October 2011 edition of the PM Networks (the PMI magazine) covers a story about the lessons learned of the great rescue on the Chilean Coal Mine disaster. That single page article questions whether we have learn our lessons from that. Below the main text, a highlighted text area mentions how challenging the management of the rescue project was.

I was then wondering when somebody will would come up with a film on that thinking on how dramatic of series of events of the rescue. Thinking further on the same thought, I was thinking why we like great movies. Specially the action movies. Recall ‘Matrix’, ‘Day after tomorrow’, ‘Anaconda’, Independence Day’, ‘etc. Do they have anything common and what those films to do with Project Management?

Lets park project management a bit and see what is there in common in those films. There is a character or group of characters (lets call them heroes) that is trying to rescue or destroy or achieve something. Be it the world or any other thing.

Let me recall something. What is the definition of a Project? According to PIMBOK version 4 – It “is a temporary endeavor undertaken to create a unique product or service”. It has a start and  end.

Do you smell something here? What is there in the Independence Day? It is to destroy the aliens – “a temporary endeavor” and by destroying the aliens, the word is saved. – “a unique service”. Are we talking about a project here?

Let’s look at few more details here.

  • Do we have a schedule here? Yeah very tight schedule. Take Independence day. Capton Miller has only few hours
  • Aren’t they having technological, human resources limitations? Plenty. Take independence day
  • Aren’t they having conflicts in the team? Always, otherwise the movie will not be that interesting
  • The list goes on and on and all those are characteristics of real project constraints and parameters

Let’s look at these stories in these films in a different angle. What are those Super Hero characters like Captain Steven Hiller in Independence Day do? And who are they?

Aren’t they ‘Project Managers’ and don’t they manage ‘Projects’? Be it “saving world”, “protecting a kid” or “killing Anaconda”, “Saving Private Ryan” or anything.

These heroes are high performing Project Managers who manage their Projects in extreme conditions and with many unknowns including Aliens. They are super-efficient in getting their team to achieve the objectives. They always have bad luck to start with but ended up having luck in their side. I wonder what if those super project managers sit for PMP certification.

We love those movies where the project (story) of the movie is really challenging. More the challenge, more we love the movie. We love the movie when the Project Manager is performing under tremendous difficulty. More the difficulty, more we love. I still wonder as project managers, why we really love those projects in the silver screen but not enjoy that much when we face with real projects in much better conditions. Answer may be the human nature.


The Bad Side of Prototyping

You may have heard many good things about prototyping. How much money it has saved, how much time it saved, how much effort it saved, etc. Those are absolutely true,  nothing wrong with them.

But think a second, is everything is good about prototyping? Do we have any downside of it? Well may be. Lets look at that further and focus only on the throwaway prototypes here.

It Kills Thinking

What? Should the prototypes suppose to generate ideas? Yes it is true but;

Imagine that you have a busy customer. You discuss the requirements with him (may be in high-level) and step by step, you come up with the prototype. You will get the feedback on the Prototype. But when time passes (and  if the customer gets busy) he tend to agree with what you come up without much thought from his end. The main reason for that is customer knows that you have got hold of the requirements and therefore he takes easy and pass the responsibility of requirements to you. Good to be a customer. 🙂

Secondly what about the development team? Isn’t it common that when you have a prototype, they tend to follow  exactly as in the prototype rather than thinking what is correct? Need not to mention that Prototype can be wrong. One common excuse on this lack of thinking is that the prototype has being discussed many times and agree with the customer so that is the ultimate truth and why change it. This happens specially if the person who did the prototype is not a permanent member of the team.

Effort of Maintenance and Level of Confusion

Once you build the Prototype, you need to maintain it. If not, it can lead to many confusions.  There are two situations where a half baked prototype can lead to confusions.

  • In the Middle of Requirement Elaboration – In this case, you start building the prototype to keep the requirement elaboration flowing. Then after each round of discussion, you keep on updating the prototype based on the feedback. After sometime, you get tired of updating and most importantly now you are familiar with the  logic of the system. These two factors lead not to update the Prototype. Sometimes you tend to refer to the meeting notes. The consequence of this is that you are nowhere with the requirement documentation. The Prototype is not complete as well as there is no proper requirement document.
  • During Development – Secondly even if you lucky to sign off a complete prototype at the end of the requirement elaboration, but there will be many further discussions during the product development. These updates to the requirements get rarely reflect in the Prototype. This can lead to problems when the acceptance testing is done.  When the Prototype is used as a requirement document, then you will find it not updated and confusion happens on what is the correct requirement.

Therefore it will become mandatory to maintain the Prototype if you start building it and to maintain a Prototype throughout the Project Life Cycle itself is a project of its own.

No Documentation

Isn’t it good? May be in certain times, but not always.

The reliance of Prototype will eliminate or reduce the requirement documentation. This can lead to many different kind of issues. To list a few

  • Difficulty in freezing the scope –  Many customers would require a requirement sign-off. This is difficult when you have a Prototype.
  • Inconclusive Requirements – Certain requirements may not be conclusive. For example, it is difficult to describe the different kind of data which will be listed in a grid, through a Prototype. Therefore the developer will not have an understand what sort of data and what characteristics of them to be expected (Domain of the data). To explain further, lets say you have a Grid and you are worried about the alinement, width of the column, etc. A comprehensive document can give inside into those unlike a Prototype.
  • Typical Issues of Lack of Requirements Documents – For example, product not confirming to what customer wants, bugs, etc. etc.

What to do with Business Logic

It is true that a Picture is worth of  1000 words but there are things which Picture can not describe. For example, it is very difficult to describe a workflow using a Prototype. In general terms, the Prototype is a very good tool to explain the User Interface but it cannot describe the Business Rules of a system in the same effectiveness.


Loss of Focus

On a blog post in a different line of topic in Prototype, David Bernstein describes that users focus on what is missing rather than what is there in a prototype.


I am a strong advocate of prototype and in which I have seen many benefits (not to mentioned that sales team uses Prototypes win projects as well). I just wanted to list down few points where the Prototyper should be careful so that he can avoid those negatives and come up with great results.

Should I be ever worried

Why humans get worried

Not a question directly related to Project Management but, this is something we all tend to do every day, every minute.

I was inspired by this video about this remarkable man, and I happened to ask the question to my self: Should I be ever worried?

In this short blog I want to discuss how humans get worried although it is my expertise but still it is my interest. At least my view point.

The very next millisecond I asked the question ‘Should I be ever worried’, I found the answer. Should I be every worried – NO I should never be worried. But I know that I was/am worried over many things.

This lead me to another question. Why I am worried?

I see only two sides to why people are worried, which includes me. It all boil down to opportunities.

  1. When people does not have opportunities, they are worried
  2. When people have opportunities, also they get worried
Lets discuss this little bit more

No Opportunities

There are many angles to why and how the opportunities evades us in our lives. At birth we loose opportunities, when we work – we don’t get all the opportunities, when we live – we loose opportunities, and list goes further and further.
  • We don’t born with all the opportunities in the world. We don’t have control over how we born, where we born, etc. People like Nick Vujicic, they are born with almost with no opportunities, they even cant do a simple thing like holding hands. It is remarkable how Nick has come out of this.
  • But how many times you ever have worried about that you are not born with what you want? We worry about lost opportunities because we born like ourselves.
  • For some people there are no opportunities to have good education, to satisfy the hunger, for clean water, clean air, etc. etc. Let’s keep the basic necessaries aside, but haven’t you worried ever in life because of not having the opportunity to have what you want?
  • At work, how many times we worry for the opportunities that does not come our way. Carrier progression, no recognition, when we have a tough day at work, etc.
It is human nature that we tend to worry for the opportunities that we tend to miss or loose no matter how many opportunities we have at our disposal.

When we have opportunities

People also get worried when they have opportunities; not only when they don’t have. What? Think that you ever worried about making a speech at public, at your wedding, at the exam, etc. You don’t really use the word ‘Worried’ for these but you tend to say that I am ‘exited’, ‘butterflies in stomach’, ‘nervous’, etc. Bottom of it, you are worried.

If you think why you worried when you have the opportunity, for example in case of a speech, exam, etc. you will find few reasons.

  • Fear of failure/rejection – it can be a speech, exam, etc.
  • Doing extra work – if you are to pass an exam, you will need to work extra. Isn’t this worrying?
  • Having to move out from your comfort zone –  people are pretty good keeping to their comfort zone. This was very well described by Kumar Sangakkara in one of his articles in 2006, long before he made him famous for his MCC speech at Lord’s England. He called it pushing the envelope.

What should we do

As I was going deeper in to my original question of Should I be ever worried, I had to change question to “What should I do to not to be worried”. I see only few things I have to do.

  • If you are worried because of you don’t have opportunities, “enjoy what you have”. That is what Nick Vujicic has done
  • If you are worried because of the opportunities that you have, “go there and just do it”. You cant control results, but you can control what you do. People will fail and you are not the first person who failed. Even if you are the first, there will be many who will follow.

The most important thing in life is to enjoy what you got and what you do. As Steve Jobs said in his famous speech “How to Live Before You Die“, live today as the last day of your life.

Doing Agile- Product Owner

Have you ever heard of the following comments?

“You are the expert, you tell me what to do”

How about these comments?

  • “I will not be able to participate the meeting today and if you have any questions, pass them via mail”
  • “I have given you all my requirements. Now you can run the project”
  • “I will be little bit busy this week as I am working on an important proposal. Since you have good understanding about what I want, let me know if there is anything you can’t resolve

OK, let’s discuss some details.

Although Agile was first introduced in early nineteen nineties, there are many organizations that haven’t done its first agile project yet. Refer M&T 2008 survey.

There are many issues that an Agile team faces when they tries to use Agile Methodology with a customer organization that does not have previous experiences in Agile.

Let’s take Scrum and start with Product Owner.

Who is Product Owner?

Let’s try to look in to the definition in order to start the discussion. Let’s see what Mountain Goat has to say about the definition.

According to their Redistributable Scrum presentation, PO,

  • Define the features of the product
  • Decide on release date and content
  • Be responsible for the profitability of the product (ROI)
  • Prioritize features according to market value
  • Adjust features and priority every iteration, as needed
  • Accept/reject work

The definition is pretty straight forward and let’s sees how a typical Scrum project would happen for a customer organization that does not have previous experiences in Scrum or Agile.

What is happening?

Now let’s run the project in fast forward mode. The main character is a person who is trying to set up the project. Be it a Project Manager, Scrum Master, Senior Team Member or Head of PMO.

Before starting

  • You request that the Product Owner (PO) role should be played by a person from customer’s organization. The response?  You will get a name of a person immediately.
  • Then you will explain the process, roles, responsibilities, etc. to the Product Owner and everything is perfectly understood by the PO.
  • Then you will put your demands to the table. For example, the PO should be there in Sprint Planning Meeting, Daily Scrum, etc. Response? Every demand is accepted.

So with everything going pretty well, you are pretty happy and excited about the new project and its delivery.

Sprint 0?

  • Now you ask the PO to create the User Stories.
  • Then after couple of days, you will get a “2-3 page document” that describes the system in high level.


  • Then you will send your User Story template and ask him to document the requirement according to that format.

Let’s discuss some details now.

Typical issues when you have customer PO

  1. User Stories –  What is that? Never understands the User Story template and usefulness it (well “never” is bit of exaggerate but it is very rare this understanding is there)
  2. Product Backlog – OK, I will do. But never creates the Product Backlog (PB) correctly
  3. Requirement ownership; That is me – But the requirement ownership is pushed to the project team when the project progresses
  4. Agile process – What is that? Never understand the process related to Scrum/Agile
  5. Sprint Planning meeting – Good to have.  This meeting is a meeting where the development team explain their version of requirements to the PO.
  6. Scrum Meetings –  I will be there. If you find the guy, you are lucky.
  7. Release Demo – This is what I was looking for. Yes you will find the guy attending. He will be mostly happy with what the team has produced. But he will always has the question why functionality X is not there in the release – Where the X functionality is never even planned at the release.
  8. Agility- OK, I can change anything. Misunderstanding of Agility. When you initially talk about agile process, the response would be “yeah I have heard about that and it’s good that we are using it”. But what are the thoughts behind those words? Ha, we can change everything.
  9. Retrospective- Everything is fine. He will provide very good feedback about working with the team – Of course the team deserves it as they have taken the burden of PO and come up with great results. But availability of PO, commitment of PO, etc. never discussed in the retro.
  10. When do you finish –  My demand. Always wanting to know when we can finish the development. Exact date, not possible in Scrum (at least in the start of the development)

Implications to the Project

Let’s see how the above points would affect the project.

Requirement Ownership

If you look at the problems related to requirements in the project, (a proper PB will never come from customer and requirement ownership slowly pushes to the team as project progress) what would typically happen is that the project team gets the requirement ownership. This means we would have

  • Missing requirements
  • Wrong requirements
  • Incomplete requirements

This kills the foundation of Scrum and there is a great risk of wrong product being developed before somebody catches it.

Also this would require deploying shadow resources such as “Proxy PO”, “BA”, “Project Manager”, etc. This makes the cost of development higher than usual.

Lack of understanding of Scrum process

When there is no understanding of the process, there will be no understanding about the activities, tools, techniques, etc. which goes with it. For example, what is sprint burn-down is and the benefits it would give.

This would lead to two major problems

  1. Customer is always curious about what is going to happen and how the team would work to achieve the final milestone.  This would lead to a situation where customer is not certain about the things going on with the development team and the bonding between the customer and team is not that cohesive.
  2. There will be demands to the project team from the customer for things that are not possible to satisfy from the Agile model. For example when the team will finish the project, etc. This leads to a situation where the team has to revert to non-Agile tool and techniques to satisfy those demands as there is pressure from the management to satisfy those in order to keep the customer happy. For example, how many of you have seen, teams preparing MS project plan to find out the end date in addition to the scrum tools?

This situation will lead to

  • Duplicate of work
  • Lack of trust towards Scrum process by both the team and customer
  • Extra pressure to the project team due to the demands that cannot be satisfied

Lack of participation to the meetings and lack of enthusiasm

  • Lack of guidance to the project team resulting project team moving in not so correct direction
  • Taking un-necessary effort for the tasks that should not be there in an ideal Scrum. For example requirement elaboration, documentation, etc. This lead to a situation where the team is being distracted from their main tasks in order to perform above mentioned supportive tasks.
  • Need to deploy shadow resources such as “Proxy PO”, “BA”, “Project Manager”, etc. This makes the cost of development higher than usual.

Miss-interpretation of Agility?

This miss-conception of anything can be changed anywhere is deadly dangerous to the project. There are many situations that during the Sprint, the requirements are changed, release dates are changed, etc.

  • When requirements are changed in the middle, those are not well thought of and never properly planned. This will make wrong functionality being developed, regression issues, etc.
  • Also this will lead to requirements being conflicted with each other.
  • With this it is no possible to find out team’s real velocity.

Impact of biased retrospective

Answer is pretty simple.  The improvements needed from customer are never done and none of the above discussed issues are ever corrected.

Reasons for the above Situations

  1. Customer is the King – Typical customer supplier relationship makes customer to pass everything (especially boring tasks) to supplier. In most cases, the supplier team is not strong enough say no to that. Even if there are courageous personalities in the team who can do that, those people are normally killed by management of supplier stating the importance of customer, etc.
  2. Conceptual difference – Scrum and Agile are conceptually different from traditional approach which customers are used to.  Therefore making it little difficult to understand the concepts and specially usefulness of them.  For example, you don’t talk about team velocity, you don’t estimate work in story points. Instead in traditional world you estimate man hours and give them a fixed finish date.
  3. Time to enjoy – For some customer PO, working on a supplier project is an opportunity to relax from his tough day today work. Why? In a failure, there is supplier project team to take the blame no matter whose fault is.

What should you do?

  • Project is the king. No matter what happened, it should be both customer’s and supplier’s responsibility to ensure that the project is successful. Therefore customers should learn to be more flexible and suppliers should learn to be stronger.
  • Education. If you find a customer who does not have previous exposure to Scrum/Agile, it should be a part of the project process to run a workshop to educate them as well as if possible to ask them to go on a professional training. May be it is a good idea to have at least one person from customer to be certified as a certified scrum master.
  • There should not be any compromise to process. Unfortunately the process is as good as people it runs. But the project teams should always try to adhere to proper process and should not find alternatives. For example, project teams should not employ “Proxy BAs” and instead should push customer to do the work properly.

Why blogging?

Why blogging? – Is a very good question to be answered in my very first blog entry.

Lets have a hypothetical discussion between a blogger and a curious person.

Mr. Curious Person: Hi Mr. Blogger. I had this question for sometime in my head now. Since you have been blogging for so long, I think you are the correct person which I was searching for. Why do you blog?

Blogger: Well you know that I have been in this field for so many years now and I have got lot of experience in these subjects at this moment and I have been there for so many conferences and spoken to many pundits regarding …

Mr. C. Person: Hold on a second, can you make it little short?

Blogger: All right, I will try. Lets say that I want to share my knowledge and experience on my expert areas.

Mr.C.P.: Pretty good blogger, any other reason?

Blogger: Well let me think… Nobody has asked this question from me earlier. I think the only reason is to share my knowledge.

Mr.C.P.: Well you think you spend some hours per day in your life blogging just to share the knowledge? As an ordinary person, its hard to believe.

Techy: Lets say that I want to be known by the industry

Interviewer: Here you are. I knew knowledge sharing is not the only reason. OK lets see whether you have any other reason?

Blogger: No I don’t think there are any other reason. Wait may be I am blogging because other people are doing it. I don’t want to be behind the trend. You know I am a fashionable guy although I am an experienced techy.

Mr.C.P.: OK, good. Anything else?

Blogger: I want to express my self to the whole word.

Mr.C.P.: OK, good. Anything else?

Blogger: Not that I can think of.

Mr.C.P.: Thank for your time and comments. I think I have now got some understanding of this.

Blogger: You are welcome. If you want to know more about me, you can have a look in to my blog.

Alright, Lets move out from that interview.

Anybody dare to asked me the question why I blog? Don’s ask that question from me but what I will tell you is that I am an ordinary blogger.

PS: There was another discussion happened between the Interviewer and Techy next day when they meet each other at the club.

Blogger: Hi Mr. Curious Person, it was a really good discussion yesterday. You know something… I was thinking why I am blogging even after our discussion. I found one another reason why I do blogging. Which is “to learn things”. You know when you try to teach somebody, by doing that you will learn a lot as well. So before I post a blog entry, I do lot of reading and learning.

Mr. C. Person: OK, great to know. Thank you.

The first blog

Dear world,

I think this is my 4th blog. Out of first three blogs that I have created, some of them did not have a single post. One blog (Which I don’t remember the URL) has three posts which was back in 2006.

I will keep my own fingers crossed whether to see this blog will go the distance. 🙂

In this blog lets talk about everything but as any ordinary person, I will talk about what I know.