Posts Tagged ‘system methodology’

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…

The Specialist versus the Generalist in Agile

Tuesday, February 9th, 2010

This contribution came from one of our regular writers – Venkatesh Krishnamurthy.

The topic of Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions. I too have my personal opinion about this topic.  Let me start this discussion with a few definitions.
Put it in a simple way,

  • A Specialist is some one who knows a “bit more” about something. In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc
  • A Generalist is some one who knows a bit about many things.

The question arises, should we have specialists in the team or generalists in the team.   Each of these techniques has its own pros and cons as explained in this article.

My opinion is that, every individual is passionate about something.  Sometimes they get to express it and get the opportunity to pursue the same, but many won’t get this chance.  People pursuing their passion end up becoming true specialists.  However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.

Is there a problem being a Specialist ?

Many Agile evangelists say specialists are not good.  However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.
Let me give you an example, most of the software companies (that I have seen so far)  have limited number of  Architects and Database administrators and mostly these roles are shared among various projects.  Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements.  At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper.   This is a challenging situation right ?   How can we make use of the DB admin in handing this situation as he is the only one available.

Let us review couple of options on hand

Option 1:

Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed.   But doing so might make the current client unhappy

Option 2:

After completing the current assignment, go back to earlier project, understand the defect and fix it.  This may not be possible as the defect is critical and needs immediate attention

Option 3:Split time between the current requirement gathering work and fixing the defect.   It has been proven that  multi tasking reduces efficiency and productivity.

Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders encourage generalized specialists.

How to build Generalized Specialists ?

While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.  In such instances,  I apply what is called “Backup Pattern”.  This pattern name is my own invention.  While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other.   This provides an opportunity to have backups (in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks.   However the same backup personnel  would continue to have their own specialization.  The team members could volunteer to be backups.
Here is an example of a table showing my backup pattern technique

Module Name Skills/technology Primary Backups
Billing JSP, Java, Hibernate Rashmi Rohit, Chandru
Dynamic IP Generation Java, C++, Tcp/Ip Jim Chandru, Rashmi
CMTS configuration WAS, TCP/IP, REST, XML Chandru Jim, Rohit

Above technique has helped me in tackling the issues of specialization.  This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.

Conclusion
Having an extreme form of  all Specialists or Generalists is not healthy for any project.   There should be balance between these two types  and decision to have generalists or specialists should be based on specific context.

Invitation to Participate in Research: Impact of Contemporary PM Frameworks on Project Performance–Queensland University of Technology

Thursday, October 29th, 2009

This is forwarded from QUT.
The APM Group UK Limited has selected the Queensland University of Technology http://www.qut.edu.au in Brisbane, Australia–a major international provider of project management education and research–to investigate the impact of contemporary project management frameworks on project performance. This offers an exciting opportunity for you, CIOB members and your clients to contribute to leading-edge project management research and materially influence improvements in global project management practice.
Our research will primarily focus on:
• four geographic areas: United Kingdom, Europe, United States and Australia; and
• three major project domains: ICT (information, communications and technology), construction (e.g. civil, building, infrastructure) and ‘people intensive’ projects (e.g. business transformation, health, social welfare).
Consequently, we are seeking interest from experienced project managers who use PRINCE2 or other project management frameworks (within the four geographic areas and project domains listed above) to participate in this research. The investment in time will be very small. After an initial 30 minute demographic survey, we will only ask you to commit around 30 minutes on three separate occasions over the next six months.
The research approach we have chosen known as the Delphi Method is very different from the usual one-shot questionnaire. Instead, we will survey your opinions of topical project management issues on three separate occasions or ’rounds’. After each round, we will analyse all responses and provide you with anonymous feedback on the group’s opinions. This will helps us to progressively dynamically target our research based upon your opinions. It also gives you the opportunity to consider the opinions of your colleagues and contribute further to their development. However at all times, your identity will remain anonymous.
Because of your expertise and experience, I invite you and your clients to be part of this innovative research project. If you are interested, please contact the project’s Senior Research Associate—Judy Kraatz at j.kraatz@qut.edu.au.

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.

Drill Down approach to IT Projects

Tuesday, June 9th, 2009

There is a lot of linear thinking in IT projects.  Start at the beginning and go step by step to the end.  Sometimes it is best to think in a more drill down way to approach your IT project.  Let me give an example.

Say we have a project to build an order management system.  Typically all the analysis is done followed by all the design, followed by the total build, then the testing and implementation.   Here is another approach.  After doing a high level analysis, pick the quick wins.  Do the next level of analysis on these and take them through to implementation as quickly as possible.

Suppose in the order management system, production of orders and picking lists could be done quickly and would give benefit over handwritten orders currently in use.  Suppose integration with production and accounting systems was going to take 80% of the time but you could do the orders and picking lists in 20%.  Why not do the 20% first and park the 80% until later. There are elements of agile programming in this approach but you don’t have to use a fully agile methodology to do this work.

The benefits are:

  • Payback starts earlier.
  • The project is seen to be delivering and will get more support.
  • You wet the appetite of users to get the next bite.
  • Change is less of an issue if it is drip fed to the users.

The key risk is that you will need to rework the deliverables as you work on other parts of the application.  In most cases, a little rework is a small price to pay for the benefits above.  In multi storey building construction, very often the basement car park is finished first and put into use to generate revenue as the rest of the building is constructed.  A quick return on project investment.   IT projects can learn from the construction industry.

Has anyone had experience with this sort of IT project approach?