Hidden Assumptions in a Project Schedule

I got an important insight while reading the book, Roundtable on Project Management. The book contains conversations between practitioners about project management that was compiled from discussions in Jerry Weinberg’s SHAPE forum. The book filled with pragmatic advice from people who understand the challenges of project work.

The book talks about assumptions underlying a single line in a project schedule. A single line on a project schedule describes a task that needs to be accomplished, along with the planned time to complete the task and who is responsible for the task. Some of the assumptions hidden in this line are:

  • The Project Manager or Technical Lead understand the “scope” of work for the task and this understanding is also shared by the person responsible for completing the task. Team members have clarity on what needs to be accomplished to complete the task.
  • The person assigned to the task has the capabilities to perform the task and can successfully drive the task to completion.
  • The planned hours assigned for the task is credible.

If any of the assumptions are incorrect, we have a problem! This reminds me of the message from Max DePree about Defining Reality. Preparing a credible project schedule is a good first step to define reality on a project. Without a credible project schedule, we are defying reality and not defining it (and defying reality seldom leads to desired outcomes or results!).

Posted in Software Projects | Leave a comment

Mindless Middles

Barry Oshry wrote a recent blog post on the challenges of working as a Middle. 1

Oshry states:

Middles regularly face potential sewer pipe situations. The instructions come and you pass them on. That’s what Middles do. Unfortunately, that’s what Middles may do blindly and reflexively without examining the instructions and considering the consequences they are likely to have. This is what it means to be a Mindless Middle. The challenge for Middles is at all times to maintain their independence of thought and action, and then to have the courage to act on that judgment.

I read the blog post and nodded my head in approval. I tried to think of situations where I had behaved mindlessly as a middle and none came to mind! Then, the next day, as I was driving to work, I realized that there were instances where I had been the sewer pipe and was the Mindless Middle that Oshry talks. What struck was that I did not feel like I was being mindless at those instances!The bigger problem is that it is hard to recognize or realize that we are being mindless. It is hard to observe what you cannot see!

When I replay the instances where I was mindless in my head, I realized that there was a strong inclination on my part “to follow the orders” and not “rock the boat”. The story that Barry narrates also made a lot of sense. As a Middle, it is easy to believe we are powerless. By shedding light on this phenomenon, Barry shows us that there is another way that is available to Middles and that we do have the power to act and use good judgment.

I was reminded of Barry’s lesson while reading about the incident at the end of the NFL game between New York Giants and Tamba Bay Bucs. At the end of the game, with the Giants in a victory formation, Bucs coach Greg Schiano asked his players to knock Eli Manning. Giants’ coach Tom Coughlin was livid at this tactic and yelled at Schiano during the post-game handshake. Coughlin felt that Schiano’s call to go after the quarterback and offensive line during a kneel-down formation could have hurt somebody. The entire Giants team felt it was a cheap shot and was unwarranted.

After reading about the incident, I thought about the Bucs players. I believe, NFL players understand the health risks of playing the game and would not want to intentionally hurt or injure a player. I saw the Bucs Players acting as the Middle in this scenario. They got a clear instruction from the Top, their head coach, to go after the quarterback. Could some of the Bucs players resented this move from their coach? Did one of them feel they were putting the Giants in a risky situation and could potentially jeopardize a player’s career by injuring them? Wasn’t this the same situation that Barry Oshry mentions? Did one of the players not go after Eli even with clear instructions from their coach? I don’t have the answers to these questions.

The other day, I saw an article from Justin Tuck, NY Giants player, who said that he would have said No if one of his coaches asked him to do something similar.

Tuck said:

“If Perry Fewell told me to dive at a guy’s knee, when we were losing, I would say ‘No,’ ” Tuck said.

I reflected on Barry’s article and this football incident and realized that being “mindful” as a Middle requires a lot of courage. I believe Barry has given us the power of increased awareness and the power to use our good judgment even in tough circumstances.

  1. You can learn more about Oshry’s system model at the following link
Posted in Management | Tagged , , | Leave a comment

Define Reality

In the book, Leadership Is An Art, Max DePree talks about the responsibilities of a leader. Max DePree has the following to say:

The first responsibility of a leader is to define reality. The last is to say thank you. In between the two, the leader must become a servant and a debtor. That sums up the progress of an artful leader.

I found Max’ characterization of a leader’s responsibilities very refreshing. Most definitions I had studied talk about having a vision, influencing people, and getting work done.

I thought about what Define Reality meant and whether it was applicable to Project Managers (PM) and Technical Leaders (TL) working on a software project. The concept made a lot of sense and I felt it was a great way of looking at a leader’s responsibility. I tried to brainstorm various ways in which PMs and TLs could define reality on a project and came up with the following list:

  • Clearly understand what they know and do not know
  • Ensure that stakeholders clearly understand what is happening on the project
  • Set clear expectations with team members  on what needs to be accomplished and when
  • They are congruent and do not feel afraid or embarrassed to express their thoughts, feelings, and opinions
  • Understand the constraints (time/schedule, money, scope, personnel, resources) facing the project
  • I also felt that “Define Reality” was a process. The PM or TL has to perform the following activities throughout the course of the project:
    1. Understand as accurately as they possibly can all the aspects that affect the success of the project –
    2. Ensure that they communicate this understanding to all stakeholders
    3. Refine their understanding of the project as they go along by being open to any pertinent information
Posted in Software Projects | Tagged , | 1 Comment

Inspiration from John Bogle

John Bogle has been an inspiration in my journey of personal and professional growth. Whenever I read or listen to John Bogle, I always walk away with an uplifting feeling. Mr. Bogle’s personality flows through in his speech and writing. His messages have always struck me as authentic, idealistic, and bold. I see John Bogle as a determined and courageous visionary who has lived his life in harmony with the principles and values that he believes in. Suffice to say, I have the highest respect and admiration for Mr. Bogle. 1

I came across John Bogle thanks to Joel Spolsky. In one of his posts, Joel mentioned his interview with Greg Gallant at Venture Voice. I started listening to Greg’s podcast and eventually he interviewed John Bogle.

The interview resonated with me and I gained a lot of respect and insights after listening to John Bogle. 2  I would like to share some of my insights with you:

  • Distinct Voice

John Bogle’s voice made a big impression on me. I found it to be distinct, powerful, and unique. Mr. Bogle’s voice carries the force of his personality. If you listen to the interview, I would recommend you pay close attention to the voice modulations.

When John talks about principles that are dear to his heart, his voice depicts confidence and determination.

During the interview, John narrates the instance when he was fired. His voice shows his anguish at a grave mistake he made. John then immediately talks about taking responsibility for his actions and his voice now exudes courage and the strength of his convictions.

While discussing entrepreneurship and what it means to him, I could sense a deep joy in his heart.

  • Power of Values 

Starting at the 28:00 minute mark in the interview, Greg discusses Vanguard’s business model which is “predicated on keeping the cost low” and asks John for his advice to entrepreneurs on “keeping cost low“. When I mentally formulated a response to this question, I was thinking about cutting wasteful spending, paying attention to expenses etc. The response from John Bogle blew my mind. Here is John’s response:

Well, the first thing that happens, is you have to realize, that about half of the cost, little bit less than half maybe, that a mutual fund incurs are profits to its managers. Profit margin in this business is pretty close to 50%. So, if you eliminate that, which the Vanguard structure does and it basically rebates that profit to the shareholders. You all of a sudden have cost 50% below the competitors. So to give you kind of a homely example, if the average cost is 1%. You are all the way down to 0.50 or 0.60 simply by getting the entrepreneurial profit out of the equation. A good start! The rest of it is aggressive cost control.

Frankly, I was stunned. John looked at the entrepreneurial profits as the first place to start cutting costs! Wow! I believe it takes a person who sincerely and deeply cares about  his role as the steward of his Client’s financial interests to pursue this course of action.

John goes onto expound his philosophy of cost control. I was reminded of Roy Posner’s article on The Power of Personal Values while listening to this portion of the talk. Roy mentions that

A value is a belief, a mission, or a philosophy that is meaningful. Whether we are consciously aware of them or not, every individual has a core set of personal values. Values can range from the commonplace, such as the belief in hard work and punctuality, to the more psychological, such as self-reliance, concern for others, and harmony of purpose.

The “business value” of cost control permeated throughout Vanguard. Vanguard lived, executed and based their decisions using this value as a guide. I am not surprised by the tremendous growth of Vanguard given such a relentless focus on values such as Customer Service and Cost Control. Keeping costs low was not just a slogan. It felt like a way of life that Vanguard had chosen to serve a higher purpose!

  • Vision and Determination

John Bogle has the powerful mix of idealistic vision that he matches up with his indomitable determination and will to achieve his goals and live according to his beliefs. I would recommend that you listen starting from the 23:40 minute mark of the interview where Greg talks about how he was able to mix idealism and execution. John has a wonderful quote at this point:

First, The Lord has created few people with greater feeling of determination than I have. I asked my kids once. What word would they use to describe me. I asked them separately. All of them said the same thing. Determined.

John mentions 3 qualities that characterizes him – Determined, an intellectual turn of mind that is driven by Curiosity 3 and not brilliance, and a Contrarian who is not afraid to fight the good fight and do what it takes to do the right thing. 4

  • Building a company

John talks about building a company and the values at Vanguard starting from the 32:30 minute mark. Vanguard uses a lot of nautical metaphors in everyday communication. The name, Vanguard, was inspired by the battleship HMS Vanguard commanded by Lord Nelson in the Battle of the Nile. Vanguard refers to its employees as crew members, the cafeteria is called the galley. They heavily use nautical phrases such as – Stay the course, Press on regardless

I found a person who enjoyed his work and was very thoughtful about the culture in Vanguard.

  • Deeper message 

There are a lot of great quotes, honest messages towards the end of the interview (starting 49:15 minute mark). Here are some of my favorite ones:

If I were persuaded it would never happen, would I start doing things differently? Not at all. I would do them even stronger. You know, Somebody has to stand up and be counted in this life.

Entrepreneurship is about the joy of creating. That’s what Tom Peters tells us and he is right. The joy of success for its own sake. The joy of changing the world a little bit for the better.

Nobody in this business had more fun than I had. Nobody. And it’s fun to take on the establishment. It’s fun to have some determined ideas and see them implemented.
There is nothing like the satisfaction of a good fight well won.

The mutual fund industry didn’t need Vanguard. No industry needs Vanguard. But, all industries need A Vanguard. That is, a company that says, I see what you are doing, understand what you are doing, I am going to do it differently. And may the best ideas win.

I think I have left no doubt how much I enjoyed this interview. I do have to mention the excellent job Greg did as the interviewer. He asked thoughtful questions and gave John the center stage. He led the conversation beautifully and the conversation had a great feel to it. Thank you, Greg!


  1. While writing this post, I was reminded of the famous line in the movie, As Good As It Gets, uttered by Jack Nicholson to Helen Hunt – You make me want to be a better man. John Bogle inspires me to be the best person I can be!
  2. The MP3 of the interview on the venture voice page is broken. I was able to download the MP3 using the following link.
  3. John mentions that curiosity is about asking questions such as Why does that happen? How does that happen? Is there a better way to do it? These questions are quite relevant to software projects, too!
  4. John Bogle had a strong sense of who he was and the principles he stood for. He understood his strengths and weaknesses. He mentions how he frequently argues with himself about principles, policies, and outcomes. He seems to live Socrates’ ideal – Know Thyself
Posted in Personal Growth | Tagged , | 1 Comment

5 Key Questions for every project

I am a regular reader and fan of Glen Alleman’s blog – Herding Cats. Glen writes an insightful blog about Project Management. Glen constantly re-iterates the 5 Immutable Principles of project management. The principles are stated in the form of questions that the project team (or at least the Project Manager) needs to answer.

Why are these questions important? Thinking about and answering these questions help us increase the probability of project success. I love these 5 principles as they are applicable to all project regardless of size, scope, cost, and technology. I have found these questions and principles to be highly relevant in various scenarios – delivering an enterprise data warehouse, planning a marketing campaign, expanding your services to a new market segment or creating an web application.

The 5 Immutable Principles as outlined by Glen are:

  1. Where are we going?
  2. How are we going to get there?
  3. Do we have everything you need to arrive on-time, on-budget, and on-specification?
  4. What problems are we going to encounter along the way?
  5. How do we measure progress to plan?

These principles are simple, profound, and highly effective. These questions get to the core of a project and help us determine if the project is on track. They enable teams to orient in the right direction.

So, how can we use these 5 principles in our day to day project work.

  1. When you join a new team, consider finding out the answers to these 5 questions.
  2. If you are a Technical Lead or Project Manager, determine if you have credible answers for these 5 questions. If not, are you certain that the project can be delivered successfully?
  3. When you are reviewing a project, start with these 5 questions. You will gain enough insight to figure out if the project is on track.
Posted in Software Projects | Tagged | Leave a comment

Insights about Software Projects – Part 5

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: All Problems are People Problems

One of the key insights I have learned from Jerry Weinberg’s book The Secrets of Consulting was that “all problems are essentially people problems”. In the world of software projects and technology, this may seem ironical. I have lived and observed the truth behind this insight on several software projects and it is useful to always keep this insight at the back of our minds.

As we try to create more complex products and work on complex projects, it is easy to believe that our problems and challenges stem from technology. As Virginia Satir correctly noted – Problems are not the problem; coping is the problem!

What matters is how we respond and combat this complexity. We always have more choices than we think we do. This also means that we have to take responsibility for our actions and failures (and the pressure is so much more!).

I have noticed that in situations where something goes wrong on a project, my initial knee-jerk reaction is usually to blame the circumstances and the environment. However, I have found it to be extremely effective and beneficial to stand back and ask myself the question – How did I contribute to this situation?

I always find that there is something I did or did not do that led to this situation. Once I stop blaming and get back to my power zone of determining what needs to happen, what actions I can take to facilitate a solution, and who I can approach to help me with the problem, the problem is almost always effectively resolved.

As Professionals, we must learn to cherish the fact that the buck actually stops with us!

Posted in Software Projects | Tagged , , | Leave a comment

Insights about Software Projects – Part 4

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Leadership and Process as our answers to overcoming the Sisyphean challenge

I believe the following ingredients helps us overcome the challenges with software projects:

  1. Leadership
  2. Process that incorporates early and rapid feedback

Leadership is an important ingredient for successfully overcoming the challenges posed by Software Projects. I have borrowed Jerry Weinberg’s’ definition of Technical Leadership. Leadership is about creating an environment that empowers people to solve problems. Software Projects requires diverse skills to succeed – Creativity, Curiosity, Discipline, Organization, Ideas, and Problem Solving. Leaders set the stage by promoting an environment where it is acceptable to fail or look bad and problems can be discussed openly without fear.

Process is very crucial to successful project delivery. More than the process itself, I believe what really adds value is if the process allows you to gain valuable insights that help you steer the “project” towards success. Process must incorporate early and rapid feedback (peer reviews, code reviews, demos, stand up meetings, status meetings). The important takeaway about feedback is that you need to make course corrections based on what you hear, see, and/or observe (using good judgment)!

An interesting insight from the Software Engineering Institute (SEI) was that effective management/leadership had to be in place before you try to incorporate new and better processes and development practices.  Process changes that come before establishing leadership have a high probability of failure.

Posted in Software Projects | Tagged , , | Leave a comment

Insights about Software Projects – Part 3

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: The primary sources of imprecision are Communication, Thinking, and Execution

I believe there are three primary areas in which we can find imprecision in software projects:

  1. Communication
  2. Thinking
  3. Execution


I have observed that common software engineering terms used on projects such as Requirements, Engineering, Quality, Design, Architecture, Testing, Schedule, Plan, Risk can be misunderstood or misused by various stakeholders. Imprecision and sloppiness in our language contributes to faulty actions and poor outcomes. I have observed several instances when I have confused Quality Assurance with Testing, Risk with Issues, and Plan with Schedule.

We cannot deliver Quality products on the foundation of weak communication. Our language must represent the preciseness that software demands from the teams. During my exploration to understand the word requirement, I found that there are several competing definitions and each one of the definitions highlights a particular aspect of the term. There is a lot of nuance and significance surrounding this deceptively simple term. This holds true for the other terms I listed out as well.

Let us say we do a quick survey of the project team and ask them to define the word requirement. Are we confident that all of them would provide an answer that is in the same ballpark? What are the effects on the project if various stakeholders and team members hold divergent opinions on what constitutes a requirement? It is important to be aware of such divergent viewpoints and determine ways in which we can precisely communicate our thoughts and ideas.


A lesson I have learned from Jerry Weinberg is that our mental models shape our actions and communication. Let us think about the word defect. What does it mean? We can think about defect as any deviation from the requirements document. We can also think about defect as a deviation from stakeholder expectations. I believe we can observe demonstrable differences between testers who hold these different beliefs. Each one will approach their work and craft differently based on these beliefs. Their actions and communication will reflect their different mental models.

The same applies to other aspects of Software Projects. What are our mental models around Leadership, Project Management, Design, and Architecture?


I have observed that it is easy to fall in love with technology and forget the end goal of a project. The goal for projects is to deliver a product that stakeholders find valuable. Once we lose sight of the goal, it is easy to fall into certain traps – We may start equating “code complete” to “complete”. Once we fall into such a trap, our plans and communication of status will not be credible. “Code complete” by itself does not add any value. The value is in delivering the product!

We need to estimate, plan and prepare schedules keeping the end goal in mind. We need to keep asking ourselves, what does done truly mean for this particular project? Is it done after we complete writing the code? Is it done after we run our automated suite of unit tests? Is it done after testers have evaluated the product? These questions help us evaluate and understand if we are closer to achieving our goals or farther away.

Posted in Software Projects | Tagged , , | Leave a comment

Insights about Software Projects – Part 2

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Software can only be as good as the teams who build it

I found a sign near a developer’s cube that said, “Around here we do precision guesswork”. I loved this sign as it touches on a very crucial aspect of what makes software projects tough and so much fun! As developers and engineers, we have to navigate uncertain environments and deliver value to Clients and users. This requires a lot of precision guesswork! ;->

Software programming and managing projects is a highly cognitive and mental endeavor that requires the ability to think big picture and be detail oriented. This is a tough juggling act and people can make the problem harder (or easier)!

Software Projects are ultimately a people business. At the end of the day, we are emotional beings and mask ourselves in the dress of rationality. We tend to use labels, generalize and can be vague about what we want.  People can cope well with ambiguity and uncertainty (and some do not!). Software cannot cope with ambiguity or uncertainty. Sometimes we fail to cope with these facts! ;->

Computers cannot think. Computers are not intelligent. Computers cannot reason. Computers cannot make value judgments. However, computers can be programmed to respond in a fashion that seems to demonstrate good judgment, and intelligence.

Software can only be as good as the teams involved in building it. The quality of our teams determine the quality of our products. Our teams are our strengths as well as our weakness. Talk about a paradox! ;->

Posted in Software Projects | Tagged , , | Leave a comment

Insights about Software Projects – Part 1

I am writing a series of posts that summarizes some of the insights I have gained while working in the Professional Services/IT Consulting world.

My goal with this series to increase awareness of important aspects of projects, promote improved thinking about projects, and ultimately help you deliver projects successfully.

You can read or view all the posts in this series through this link.

Insight: Software is a precision business

When you have developed software for some time, some things become very clear. Software will do exactly what you want it to do.

When we think deeply about software, we need to realize that it is all about 0s and 1s. We manipulate 0s and 1s (and occasionally NULLs!) and we transport 0s and 1s over the wire. It is easy to lose track of this fact as we have built enough high-level programming languages, libraries, APIs, technologies, and tools that we never have to deal with 0s and 1s directly. Just like reality, the Os and 1s are always lurking in the shadows and never go away (even if we try hard to wish them away)! This is the gravity for software projects. You have to contend with this no matter what.

What does all of this signify? Programmings forces us to be extremely precise in stating what we want to accomplish.

Let us take a regular use-case. Consider an online banking login page that asks users for their username and password and allows them to access their account information.

Here are the various decisions that a software team needs to make.

  1. What constitutes a valid username? Can it be 50, 100, or 250 characters long? Can it include numbers, spaces, or special characters? What special characters can be allowed? Are there other restrictions?
  2. What constitutes a valid password? Should users be forced to change their passwords every 3/6/12 months? How many attempts should the system allow before we lock the users’ account? What happens after the user account is locked?
  3. What is the exact error message we need to display to the user if a problem occurs? What will be the font size and position of this message? Should we even display an error message? When should we hide the message?
  4. What is the font size for the username/password label? What should we call these fields? Are we referring to these fields consistently throughout the application?
  5. Should the application support multiple browsers? If so, what browsers and what exact versions should we support?

The login page may seem to be a “simple” page on the surface. However, we soon realize that there are tons of decisions that have to be made. Each decision affects the size, scope, cost, and effort involved in completing the project. To make matters interesting, we have only scratched the surface! We have not discussed Security, Performance or Usability aspects for the page.

We need to make these decisions “consciously” as this will lead to a product that can delight our Customers/Clients. Can we ignore such decisions? Nope! One of the biggest challenges with software is somebody “eventually” makes these decisions! ;->

Let us take username. Let us say we decide not to establish the field length for username. At the time when the database modeler/programmer defines the field, she/he will set the field length! A decision is made for the product regardless of whether you agree with it or not! That is one of the reasons we need to be aware of what we are doing!

This brings up three important questions:

  1. Is the right person making the decisions that help us be successful – Creating a product that delights our stakeholders or at least meets their expectations?
  2. Are we making decisions consciously?
  3. Do we understand the impacts of our decision?

In a field that demands precision, our decision making better be very good!

Posted in Software Projects | Tagged , , | Leave a comment