New Version of Method H

March 9th, 2010

Our popular requirements gathering tool, Method H has just been updated to version 3.  A beta is available for existing users to test.

Changes include the updating of the user interface to match the colour scheme used in Project Administrator.  We also added a new tabbed screen.  The previous “H” format screen is still available but you can now see the same data in a screen where there are tabbed pages for inputs, outputs, business rules etc.

If you are an existing user, and would like to try the beta release, send an email to sales@projectperfect.com.au.  Include in the email details of when you purchased Method H.  If you have a copy of the email you received, include that to allow us to confirm your purchase.

White Paper on Maintenance and Support

March 4th, 2010

This paper investigates some of the unique characteristics of the software application maintenance & support function. It attempts to capture the important aspects that need to be considered when planning to implement processes or process systems in an IS/IT organization.

The scenario assumed is of a typical in-house maintenance function or department, and not one of out-sourced nature. The scope of the activities addressed here-in pertains to a maintenance & support function that is entrusted with M&S items or requests that need the supported system or application to be fixed or modified in some way. It does not speak to activities pertaining to level 1 support organizations such as call centers.

Read more

The Specialist versus the Generalist in Agile

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.

White Paper on Personal Project Management

February 8th, 2010

A Project Manager will likely use their project managment skills in their personal life.  This white paper talks about how those skills were used in buying and restoring an old boat.  It is a good example of how to apply PM skills to our personal life.

Read the white paper by clicking here.

White Paper on Contract Bidding and Technology Evaluation

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…

Timing is everything

February 4th, 2010

I recently helped an organisation implement a Service Desk program which was a hosted solution (ReadyDesk).  There was a considerable degree of configuration but by the due date we had most of it sorted out.  What was remaining were only minor issues that would not have an impact on customers.

At the same time, the company was switching their main IT support organisation.  In fact, the two events were to occur on the same day.  The timing was designed to put in place a more professional way to manage service requests at the same time a new IT service provider took over.  We expected a few glitches and wanted a better way to manage them.

What I didn’t take into account was that a simple task like setting up SMTP and POP3 details would cause such pain.  Firstly the old service provider took a day or two to provide details to the new provider.  Perhaps I am being cynical but there did seem to be a lack of urgency in their response.  We then found the configuration of the firewall was somewhat unconventional and that caused another few hours of untangling the setup by the new provider.  The result was that we ended up a day and a half behind schedule to get the new Service Desk software working.

The impact was not significant as an inhouse, Outlook based system was adequate to handle requests over those two days.  What was a lesson though is that as a Project Manager, we should avoid as far as possible going live at the same time as something else is happening.  It seemed sensible to switch ReadyDesk on the day the new Service Provider took over.  We did not want to have the old provider involved in testing due to a record of poor quality service.  Unfortunately if something can go wrong it will.

Earthquake in Hati – Project Management

January 21st, 2010

An event like the earthquake in Hati always raises questions of how to project manage such an event.  It would be interesting to see some comments on how you, as a project manager, would approach the situation or on what you see happening from a project management perspective.

Need for Retrospective in Project Teams

January 4th, 2010

This is an interesting contribution from one of our readersVenkatesh Krishnamurthy.  We would be interested in your comments on the item.

Every organization and every project has a grapevine running in the inner circle. When I say Inner circle, I mean the closed group of people who trust each other.

For example:

In a typical software project,  a manager(PM) with a command and control attitude, would encourage the creation of an inner circle with project team members, whose opinions are being ignored by the PM.  This inner circle group  excludes the Project Manager.  This group in turn talk among themselves and share their agonies without the knowledge of the Project Manager.

The example above of a team member inner circle group, can be extrapolated at an organizational level with the inner circle being the employee group excluding the management of the company.

The inner circle groups mentioned in the above examples are harmful for the project and the organization. They are created because the team don’t have a venue to express their bottled up emotions/thoughts/opinions.  This in turn leads to a lot of negativity.  This negativity needs to be conquered sooner rather than later.  Here is a good article, that provides techniques to conquer such negativity.

One of the ways to conquer the negativity is to provide a platform for the employees to express their thoughts/opinions/emotions. In Agile projects, retrospectives provides such a venue.  This in turn leads to healthier project and teams.

Lateral thinking to solve problems

December 28th, 2009

Here is a little lesson in problem solving.  It happened to me in the last few days.

The problem:  I have a  boat with two engine starter switches.  One is in the cabin and one on the flybridge.  When you use one to turn on the engine, you cannot stop the engine from the other.  You have to use the one you used to turn it on, to turn it off.  The starter stopped working.  Tried to trace a number of connected relays but ended up with a wiring diagram that made no sense.

The solution:  After trying to make sense of the wiring I approached it from the other end.  How would I wire up the system if I was trying to achieve isolation of the two circuits?  Woke up early on Christmas morning with the answer.  I know I should get a life but my mind works in strange ways.  As soon as I sat down and drew up the circuits, I saw how the wiring worked.

The lesson.  Sometimes trying to unravel a problem is better approached by trying to look at potential solutions and working out how the problem fits each solution.  No matter how much you think you know about project management, you can still learn from your challenges and be better prepared in the future.

If anyone is really keen, I can send a wiring diagram.  Hopefully most of you have a life and are content with crossword puzzles.

Project Managing Copenhagen

December 21st, 2009

The climate change conference seems to have come up with an outcome that pleases nobody. Looking at it from a project management view, what was the problem?

Before any project starts, there should be clear and agreed goals. I doubt there were any clear and agreed goals before the Copenhagen Climate Conference started. Some countries had goals of reducing carbon levels whereas others had goals of using climate change to gain investment in their countries. Some wanted to avoid their countries disappearing under rising sea levels and others wanted to protect their country’s industry. There were probably those who believed that nothing needed to be done as CO2 was not the major cause of global warming. In all, too mixed a bag of goals to ever get agreement.

It is fine to be negative, but how do you find a solution?

First get agreement to the problem.  A conference that agreed there was a problem, and we were all contributing would be a good start.  Next move on to potential solutions.  Not what someone else can do but what my country can do.  Each solution needs to be defined in terms of costs and benefits.  By ranking the solutions for each country, we can see what is possible with a minimum of cost.  They can be implemented without a conference although some might need a bit of prodding to come up with some solutions.

Given each country now has a list of actions ranked by increasing cost, we have a basis for horse trading.  If China will do this, America will do that.  If Europe will spend this amount of money, Australia will spend a certain amount.

There will be common costs that can be neutralised by everyone (or at least some countries) taking similar actions.  For example, if country A puts a tax on a certain industry, the world will buy from their main competitor – country B.  If both A and B apply the same tax, the market share will not change due to price disadvantage.

Much of the climate change debate at governmental level is about appearances.  To be seen to be doing something is sometimes more important than actually doing it.  What is needed is a mechanism that recognises that fact, and makes governments do things that will contribute to the solution while keeping up appearances.  In other words, if they don’t contribute they look bad to their own country as well as other countries.

Any project manager will recognise the creation of situations where people are forced to contribute.  Once the problem is agreed, the activity moves to getting solutions on the table, doing a cost benefit analysis of the solutions, and implementing the most appropriate one.  The trick is to get everyone behind the agreed solution.  Make them part of the team first, then use that peer pressure to force them into action.  Force them to come up with their own solutions then work as a team to ensure they implement the solution.

The other key project management problem is no clear roles and responsibilities.  Imagine if everyone in a project had an equal say in the management?  It would be chaos.  There seems to be an assumption that a government is responsible for not only the land and any surrounding sea within agreed distances.  They are also responsible for the air over their land.  Is each country responsible for their air or is the atmosphere not the responsibility of the country?  If not, who is responsible?  I don’t have an answer, but it is a question that needs debate before a solution can be created.

One school of thought seems  to be that if you put pollution in the atmosphere you are responsible.  Another seems to be that richer countries are somehow more responsible than poor countries.  Another is that the providers of pollutants (e.g. Coal, Oil and Gas providers) are responsible.  The problem will never be resolved while there is disagreement about the responsibilities.

On another level, there is no clear role and responsibilities for the management of any agreed solutions.  The countries that would not allow UN monitoring obviously believe they are responsible whereas the other side believe the UN is responsible.

Until basic project management processes are applied, climate change will never be solved.  Get the fundamentals sorted out, then you can make progress on the project.  Get agreement on the problem you are trying to solve.  Get agreement on roles and responsibilities.  Develop options for solutions.  Create teams with common goasl rather than individuals with vested interests.  Measure progress.  If this can happen – and it is certainly not easy – you have a hope of addressing climate change.