Archive for the ‘Project Methodology’ Category

White Paper on Design for Hybrid Agile Adoption

Wednesday, October 27th, 2010

In order to deal with these recent changes new software lifecycle models have emerged that promise to keep pace with the industry. Agile is one such emerging methodology that is providing: better project transparency, better requirement trade-offs, faster time to market, and improved quality and reduced defects. While Agile approaches have clearly seen judicious success in recent years, these have primarily been associated with collocated teams. Unfortunately, collocation is not an option for all Agile teams. In fact, collocation is an approach which, in some cases, has moved the industry paradigm decades back defeating the overall advantages and cost controls of off-shoring and out-sourcing.

Overcoming these challenges, “Design for Hybrid Agile Adoption (DH2A)”, is a framework defined to successfully execute agile projects in a distributed and out-sourced environment. Read More…

White Paper on Contract Bidding and Technology Evaluation

Monday, February 8th, 2010

This white paper focuses on the management perspective of different project proposal evaluation methodologies in the procurement processes. Our goal is to introduce in details as to how proposal evaluations take place in procurement management processes using both literatures and industrial experience. We list out building blocks of the process, types of models and methodologies, evaluate and unified different processes and models. We also highlight insights on what you can do to win the contracts. The references are mostly from Information Technology industry and academia literature.

The in depth technical, environmental evaluation attributes will only be highlighted in this paper. The details would not be addressed in this paper.

Read More…

RFI RFQ RFP RFT

Wednesday, September 2nd, 2009

I was asked the difference between different sorts of request documents.  There are four in normal use:

  • RFI Request for Information
  • RFP Request for Proposal
  • RFQ Request for Quote
  • RFT Request for Tender

After doing some research on the subject here is what I learned.

RFI. An RFI is undertaken at a point where it is expected there will be a loose fit between the requirements and what a vendor can provide.  If you are not aware of what is available in this particular market, there will probably be things that vendors offer that you have not considered.  The information gathered during the RFI will likely influence the requirements for the purchase.  It may be necessary to fine tune requirements after receiving a response.

RFQ/RFP/RFT. If using a more formal process, the level of detail will be determined by the type of document to be issues.

  • An RFP will have a number of ‘fuzzy’ areas where the vendor will be invited to propose a way of addressing that area
  • An RFQ will be much tighter specification however still leave the door open for negotiation around a number of points.  A fixed price may not be sought but perhaps a price range or indicative price requested.
  • An RFT will be the most detailed.  It will be used to draw up a contract and probably strict delivery criteria. You will ask for a fixed price against a fixed set of requirements.

The information provided in all the documents will be similar but the level of detail will be different.

Would be interested to hear from other people as to their interpretation.

Role of the Scrum Master – Dealing with Conflict Avoidance Teams

Tuesday, August 25th, 2009

This item was forwarded by regular contributor Venkatesh Krishnamurthy.

Have you come across teams where only a few speak and the rest listen?  Have you seen any of your team members not sharing their thoughts or participating well during Scrum meetings, retrospectives or other activities?  Have you come across any team where there is no conflict ?
Silent Teams
I would call teams where you don’t see conflict “Silent teams”.  For the sake of this article they are silent in speech, but not really silent in their mind.  The people in these teams are like any other people but all their questions, frustrations, arguments everything is happening in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others.  But there is the chance that they go and share their frustrations with someone closer to them in the team during the cafe breaks or with other close friends.

Why does this happen ?
According to Conflict Avoidance hurts Business… Individuals stay silent because….

  • We are afraid others won’t like us if we speak up
  • We fear the other person may say something worse about us
  • We wait until we’re really angry and fear loss of our tempers
  • We lack the skills and confidence needed to resolve conflict

Basically our identity getting hurt plays a key role here.

According to Ester Derby, Groups that avoid conflict won’t be able to face tough issues or handle the creative conflict that generates new ideas.

It has also been found that culture in certain Asian countries like Japan, China, Korea, India, etc have a Conflict Avoidance Culture. People in these countries are ready to keep silent during conflicts so that it does not hurt the other person or as Craig says they remain silent to create “Social Stability”. Scrum Masters, especially from these countries need to be conscious of, and ensure that conflicts are identified, brought out in the open and resolved. The team should be taught how to resolve them among themselves. Such teams tend to become self organizing much faster as compared to the conflict avoidance teams.

Here is a case study in which the team conflict avoidance led to a drop in productivity. ..

An onsite customer was very brutal with the offshore development team members. Every day he used to pick one of the team members and shout at them. Every day the conference call with the onsite customer was like attending a court where each team member was supposed to defend their work and explain what they did every hour of the day. The communication with the customer had always been one way.No discussions were encouraged. Even though everyone in the team was fed up with the customer, no one had the courage to speak up and confront him. Every day after the call, the team used to wait until the customer dropped off and then used to talk behind his back. Over a period of time the frustrations and stress lead to a huge drop in the productivity for the team.

Does this sound familiar to you?

Situations like these are all too common in organizations. As per Conflicts and Trust,

“Fear of what might happen if conflict were confronted causes otherwise proactive people to hesitate, and the cost of this hesitation is significant.”

Consider the cost of all those developers as their performance is dropping.  The unresolved conflicts keep accumulating in people’s mind and causes a huge hit on performance.

It is very important for the Scrum master to observe and understand the team dynamics. Craig Larman recommends Scrum masters ask questions like:

  • Are members avoiding discussion?
  • Is something hidden?
  • Are members truly committed to the team?

Managing Conflicts
There are techniques to manage the conflicts.  One of the most popular techniques is the Ladder of inference.

Role of Scrum Master – Dealing with Conflict Avoidance Teams

Project Methodology

Monday, July 20th, 2009

I am a danger if there is a whiteboard in the room.  I can’t help myself.  Maybe it is just that I think in patterns and design.  One of my regular attacks on the whiteboard is to explain to people how a Project Management Methodology fits with a Software Development Methodology, or an Infrastructure Development Methodology.  I have found people generally confused about where one ends and the other begins.  To me, it is very simple,  Look at the diagram below.

Project Management Framework

We start with a project management framework.  It covers such things as risk assessments, defining roles and responsibilities, setting scope, our procurement policy etc.  We can plug in any sort of project to this framework.  A Project Management Methodology tells us we should define roles and responsibilities.  If it is an application Development methodology, the roles will be different to a an Infrastructure Rollout.  They will also be different to a Construction project.

The common denominator is that we need to identify and define roles and responsibilities.  That is what a Project Management Methodology covers.  It doesn’t tell us what those roles and responsibilites are.  The bit that plugs in (Applications Development Methodology, or Package Selection Methodology) tells us that.

While some risks will be common, HOW to do a risk assessment is the focus of a Project Management Methodology.  WHAT are the risks to look for is in the plug in part.  For example what risks are common in Applications Development?  What are the common risks in Package Selection or Infrastructure?

A pure Project Management Methodology should be applicable across any sort of project – IT, Construction, Engineering, Business etc.  If you look at PMBOK, it tells you the activities that should take place in any project.  It does not talk about specific industries.  If you can get people to understand this concept, it will make it much easier to build a process for your organisation.  First construct the Project Management layer, then plug in various types of project underneath.

A white paper we published some years ago expands on the subject.  Click here for more information.