Why You Cannot Avoid Virtual Project Management 2012 Onwards

April 13, 2012 By Mridula Velagapudi

1 Comment

The emerging digital world has brought some game-changing concepts which have altered the way businesses function. It has also brought about a cultural shift in how the employees want to work. Many supplementary and supporting processes are therefore being moulded in order to support the changing business operations, strategy and enterprise IT structure.

Facebook has changed the way people collaborate and has given a boost to viral marketing concepts which can engage the target customers immensely. Cloud computing has changed the very core of how IT is accessed and utilized. Similarly, the traditional Waterfall model of SDLC is helping evolve Agile methodologies. Cubicle-less work spaces are found to reduce productivity and hence are getting replaced more and more by distributed and virtual teams. This has received additional boost due to availability of smart phones, tablet PCs & sophisticated online collaboration tools and the ability of people to collaborate effectively. Collaboration as a culture is intrinsic to people and organizations now.

Quick time-to-market with continuous development and superior quality is the name of the game now.

Because of the above trends, it is natural that as project managers we now look towards adopting Virtual Project Management as a concept habitually. Not adopting Virtual Project Management will be like sitting on a three legged chair – romancing distributed teams, working with Agile SDLC in distributed teams and adopting cloud computing models but not doing project management virtually. In fact if you are planning to go the cloud way and not considering Virtual Project Management, then you are not leveraging the full potential of cloud computing.

Let us take a simple example of an SMB which is contemplating into expanding one of its services in a niche domain of providing development & maintenance services for applications developed on CORBA (Common Object Request Broker Architecture). Being a specialized area, the SMB would want to hire subject matter experts and well experienced project managers. Now, the non-availability of talent in the location where travel to a physical office of the SMB is feasible, will not (and should not) limit the SMB from expanding its business. The SMB will make use of cloud services and online collaborative tools to engage the best of talents from around the globe. In this situation, you cannot avoid adopting the Virtual Project Management too.

In another example, consider that you are planning to launch a startup. Let us assume that you are building a software product. To reduce the upfront capital expenses, your prudent approach would be to deploy your code on a PaaS. To further keep the expenses low, you will appoint team members who are committed to work in a distributed environment so that you do not have to maintain a large office space. Obviously you will use online collaboration platform too to stay connected. Also, to build the product you will implement project management practices and under this set-up you cannot avoid Virtual Project Management as a concept.

Moving on to future from now, you will not be able to avoid Virtual Project Management and here is the summary of the WHYs:

  • Continuous and rapid change in market requirements will force you to be quick in response with superior quality of deliverables.
  • Demand for quality will ensure that you engage the best of talents.
  • This will force you to adopt distributed team culture.
  • Distributed team culture means adopting effective collaboration platforms.
  • The cultural shift that people have experienced due to smart phones and improved internet connectivity, makes them demand work-from-anywhere and that which gives them flexibility.
  • Virtual team management means managing projects too virtually for significant amount of man-hours.

The sum total of the above factors means gearing up for the Virtual Project Management.

Want to make a point? Please share with us under comments.

 

5 Top Reasons Why Cloud Computing Projects Fail

April 11, 2012 By Mridula Velagapudi

Leave a comment

Benefits of cloud computing are obvious to many decision makers now. It is a rage with large enterprises, SMBs and startups equally, mainly because of the cloud’s ability to provide the size-specific IT as a utility service.

Cloud adoption takes place in various forms in enterprises and can be for any level in the cloud stack. Projects such as integration and migration of data & systems are most commonly happening in the enterprises in order to switch to cloud. Or, even the core application development projects on cloud platforms (PaaS) are increasing now.

There is a frenzy to switch to cloud computing. The global cloud computing market is expected to grow at a 30% CAGR reaching $270 billion in 2020, concludes the latest research report Global Cloud Computing Market Forecast 2015-2020 covering the cloud computing products, technologies and services for the global market. What was once seen as knowledge gathering process has now turned into real-time implementation projects.

In the process, some common mistakes are made which leads to failure of cloud computing projects. Here are top 5 reasons for the cloud computing project failures:

1. Failure to manage and monitor applications

There is a myth that by switching over to cloud computing, the operations part of the applications are done away with. If you switch to PaaS, then the developers start coding almost immediately without having to bother about setting up the development infrastructure. They also do not have to bother about the ops part. True that cloud does change the ops scenario for developers, but it only changes the nature of the ops part. With cloud computing, you may not be bothered about provisioning, testing and/or deployment, but still you need to monitor and ensure that everything is alright with your application. After all, you will be accountable to your customers if your application fails.

Since in traditional on-premise development scenario, 80% of the developer’s time is spent on monitoring and management of the application and other IT infrastructure, it comes as a big jolt when the team and the management are not prepared to accommodate managing and monitoring of the application even when they switch to cloud computing. Unforeseen costs of operations and lack of proper application performance management process can lead to cloud project failure.

2. Failure to understand technology and legacy data

Migration to cloud computing is bound to have many integration requirements. Failure to understand the legacy data systems properly will lead to total meltdown of the cloud projects. Similarly, when developing a new application in cloud, the management or the development team may select the wrong technology for the development and hence end up selecting the wrong cloud vendor too. Naturally, if the wrong technology is selected for the application, the end result will be less than satisfactory.

3. Failure to understand requirements upfront

This is directly related to the reason #2 and is a common reason for project failures even in the traditional development situation. If you do not understand the project requirements upfront, then you will end up in either choosing wrong technology or develop something totally tangential to what your customer needs. Failure to understand requirements upfront will cause problems right from architecture design to database schemas, making test-cases and provisioning.

4. Lack of right skills-set

Cloud computing has created its own need for skill-sets, which should be specific to integration projects and development projects. Since cloud computing is relatively new naturally, the available skill-sets will not be so easily available. Moreover the available talent may lack the experience. All these put together increase the risk of project failures.

5. Failure to scrutinize the vendors

Cloud computing is relatively new and suffers from certain inherent glitches such as lack of standardization of SLAs, failover remedies etc. Failure to scrutinize your service provider can lead you to dire consequences. For example, you must understand where your data resides, what are the data security policy that your vendor follows, what are the back-up provisions, what are the disaster recovery processes etc. with your vendor. If you ignore such important issues in your SLA, then you may have to cut a sorry figure with your customer especially during a disaster situation. If the back-up policies are not robust, your project is at high risk for failure.

 

Image courtesy: http://www.improvizations.com/kronosblog/bid/28249/APPROACH-is-important-in-Workforce-Management-Implementations

Agile Software Development and Distributed Teams

April 05, 2012 By Mridula Velagapudi

Leave a comment

There is a growing trend towards working with distributed teams across the globe. Many factors are responsible for this trend. Some of the prominent ones are increasing cost of maintaining physical offices with a parallel pressing need to cut down costs, success of outsourcing as a business model, availability of internet-enabled smart devices, deeper penetration of broadband and of course the advent of cloud computing.

The combination of above factors (in any permutation) clearly indicates that future will see more organizations romancing the distributed teams to a large extent.

So what happens to the Agile methodologies for software development?

Agile methodologies are said to fix the problems that arise out of software development life-cycle (SDLC) between the customer and the developers. It is next to impossible to collect all the information regarding the application to be developed right at the beginning as there is uncertainty at the customer’s end too. It is therefore imperative that there be a continuous customer engagement and at the same time it is important that the developers adopt changes rapidly. For this developers need to have flexibility incorporated in the SDLC and Agile methodologies bridge this gap. To know more about how Agile SDLC can improve productivity read Key Practices for Agile ALM for Improving Productivity.

Unfortunately Agile methodologies assume that teams are at one place. So in the times when distributed team set-up is gaining momentum, can Agile be as effective as it would be if the teams co-locate?

In 2008, Dr.Dobb’s ran a survey with 642 respondents exploring the adoption and success rates of Agile software development. Scott Ambler presented an analysis of the survey and found very interesting statistics regarding success rates of Agile project teams. Colocated teams where everyone including stakeholders were in the same work area, enjoyed a success rate of 83% and non-colocated teams where people were in different cubicles, on different floors, or in different buildings, where they could easily get together physically if required, had a 72 percent average success rate. Projects where part of the team was at a significantly different location, such as offshore locations, had a 60 percent average success rate.

Scott also mentions in his article that within IBM, they have delivered products with agile teams of 200 people and have several agile programs of 500 or more people. Scott’s main point was to show that Agile development is scalable. And Dr. Dobb’s survey proves this point and debunks the myth that Agile development is only applicable in small co-located teams.

Clearly Agile development can be successfully adopted in distributed teams also though Agile development in distributed team set-up will need a few modifications to make it work successfully. Some of the things that could work are:

  • More detailed and easy to understand documentation for functional specification from the customer
  • Use of collaborative tools to have more effective real-time discussions
  • Use of SaaS ALM/SDLC Management platforms so that indexing can be done through features such as milestone tracking and time-sheet
  • Use of SaaS ALM/SDLC Management platforms that allow continuous interaction with stakeholders by providing regulated access to them
  • Team is educated about the Agile philosophies and its advantage of increased team productivity

Agile development in distributed teams will work; it is just that the team needs to blend into a collaborative culture. They need to choose the right web-conferencing and ALM/SDLC Management tools so that the entire team has the track of a situation. The ALM/SDLC Management tools must be able to generate gravity around the project, i.e., be able to bridge the psychological barriers that arise due to the knowledge that the team is not at the same location.

Have you had any experience in practicing Agile development in a distributed team set-up? Please share with us.

 

What is More Important in a Startup – Leadership or Management?

April 02, 2012 By Mridula Velagapudi

3 Comments

Often leadership and management are used interchangeably. But it will really be beneficial if you understand that both are not synonymous. Leadership forms an important integral part of Management.

When you talk about leadership and management for any organization, the implications of the following two statements are very different:

  1. Leadership of an organization
  2. Management of an organization

Leadership has more to do with an aura or charisma of a person which has the natural capacity to lead people, arrange for required resources, visualize and be able to sell different business solutions.  Whereas, Management is more about making sure that the execution of something is flawless or the processes are followed properly. This practice is very different in larger organizations than that in startups.

Large organizations would do well with a weak leadership but may not do well at all without management that is anything less than excellent. This is so, because once the business is established, a flawless management can help achieve revenue growth while the slack leadership can follow.

But it is not so with startups.

When you talk about startups, leadership and management take a very different shape. Larger organizations have the business in place, their market is defined (market share), resources and profits are adequate to take risks, long-standing trust exists with the customers (mindshare) and there is no dearth of talent that would want to work with them.

In startups, you have to realize that nothing is streamlined over there. Startups have limited funds and they have to make sure that there is consistent revenue inflow before their coffers dry. (I’m assuming a scenario where the investors have not yet found the idea-stage so interesting that they decide to chase the founders with their term-sheet!). Most of the time startups cannot afford salaries of the best talents and hence have to settle with skill-sets that are a notch below. If the business idea is a ‘me-too’ one, then the startups have to first kill the mindshare of their established competitor and then create their own mindshare (double-trouble). And if it is a new disruptive idea, well, you can imagine the course of path.

Often startups discover the right business model while selling. So they have to spend time and other resources to chisel or fine-tune the initial business model towards the one which seems to be the final one. Only when the final model is arrived at, can a startup start to build the market share. While all this happens, startups simultaneously put processes in place and also change it with alarming speed to fit into the ever evolving business model.

What do you think is needed in this situation?

One answer: Leadership.

But this leadership has to be very different than that needed in a larger organization. It has to include management – managing many tasks simultaneously with very limited resources at disposal. The leadership skills of the founders will have to make sure of the following:

  • The tasks and goals are defined properly and frequently
  • Tasks are executed properly to achieve goals
  • Effective relationship is maintained between the team
  • Confidence is established with the employees no matter how many times the business model undergoes a change
  • A persuasive and exciting work environment prevails for the employees to feel motivated to ‘make the difference’ and help achieve the goals.
  • Collaborative work culture is practiced to ensure that the team works in close synchronization and avoid communication gaps as far as possible.
  • Employees are always convinced enough so that they have the sense of ownership.

To nurture and achieve all this in a startup, founders have to have the charismatic ability to surround themselves with talent that is smarter and more knowledgeable than them, manage all the processes with limited resources as well as lead the team. For once, you may be able to survive without excellent management skills but you certainly cannot survive with leadership skills that I just talked about here. And that happens when you are a founder of a startup!

What is your take?

 

iPaaS – Everything That You DON’T Need For Cloud Integration to be Successful

March 30, 2012 By Mridula Velagapudi

4 Comments

As I keep writing more and more on Cloud Computing, every time I ponder about the integration side of setting-up a cloud stack. It is so because I believe that the best thing by far that has happened in IT is the evolution of Cloud Computing – the disruptive technological phenomenon – from a mere hypothesis to a reality. It will be really sad to not be able to fully use cloud services because of integration issues.

But disruptive technological progresses see supporting developments happening almost simultaneously. Integration is an important aspect for effective utilization of cloud services and has gained attention of many.  And why might the integration in cloud computing be an important aspect for the vendors to consider is explained in more detail here.

Gartner has come out with a term – iPaaS (integration-platform-as-a-service), more to present it as an ideal guide of what integration solution in the cloud should be. Gartner defines iPaaS as

‘A suite of cloud services enabling development, execution and governance of integration flows connecting any combination of on-premises and cloud-based processes, services, applications and data within individual, or across multiple, organizations.

An article by Hollis Tibbetts suggests that Gartner’s classification of iPaaS is that of a Utopian Society which is theoretically possible but not pragmatically feasible, at least not at present. The article further suggests that even if it were feasible, too many organizations may not need all the features and may end up using a very small percentage of the features. But Loraine Lawson cites in one of her articles,

If you’re not familiar with the term “iPaaS” — integration-platform-as-a-service — you’d do well to learn it, because it will be an integral part of the future of integration — even for those with established integration infrastructures, says Gartner.

Coming back to what Hollis claims…

According to him iPaaS is described as an array of features, capabilities, integration models and architectures, and you cannot buy any such product which even remotely fits the capabilities description given by Gartner. To construct a platform with such a range of capabilities may not be the right solution as most of the customers may just need 2% of all the capabilities that would be used together even in the largest of projects. Moreover, by the time you figure out Gartner’s complex iPaaS reference model, your market would have moved forward multiple times.

I agree with Hollis to a great extent. In fact I could not resist deriving the title of this article from his concluding statement.

The above two outlooks certainly prove that integration solution is the need of the hour as cloud computing gets adopted more and more, but thinking about iPaaS maybe too early in time. In Integration Solution a Must for SaaS Vendors in 2012, I have pointed out the reasons why SaaS vendors need to consider providing integration solutions as a service feature to their customers.

Simple integration solutions can be managed through API management tools in the cloud. Pure cloud stack is usually not a practical solution in enterprises and hence it is important to make different components talk to each other in the complete IT stack. Managing APIs specific to customer’s requirement is effective enough. You will even do great by using some of the available cloud integration solutions which focus on specific integration needs such as data integration and/or application integration.

Whether an integration solution provider or a seeker, you must understand that attempting to create and offer iPaaS suite as integration solution or waiting to receive integration solution through iPaaS, will cost you heavily. It will mean wasting time and resources on unnecessary complex capabilities. Hence, iPaaS is all that you DON’T need as of now unless you have a very long vision and are ready to build it for future.

The Secret to Productive Team Collaboration is Individuality

March 28, 2012 By Mridula Velagapudi

1 Comment

In an article in The New York Times, Sunday Review, Susan Cain points out that the era of working in solitude is gone. Today is the era for cubicle-less office spaces, with the idea to foster collaboration and build transparency into the work-culture. True to its motives, this approach does help in achieving the goals of corporate work-culture.

Cain further highlights in her article that research strongly suggests that people are more creative when they enjoy privacy and no interruptions. Studies also suggest that some of the very creative people are introverted. They are extroverted to the extent that they can share ideas but at the core they are individualistic and independent in nature. They are not the herd followers.

Now these two facts are sort of contradictory to each other. Why would the corporates build cubicle-less office spaces or open-space layouts to encourage more discussions as a way to foster collaboration when the higher creativity is feasible by providing un-interrupted work environment? (Do you see a case building-up here? You will, shortly).

Through open layout work places, the top management of an organization does try to build team collaboration by easing the flow of communication and access to team mates. This also generates motivation among employees as people from all echelons are seated in similar set-up, spreading a feeling of being at-par.

But this approach creates an environment of excessiveness – too much of each other and too much of efforts for collaboration. The main aim of open-space layouts gets diluted and loses focus. Open-space layouts quite naturally bring out more socialising and take away the productive energy and concentration of employees from their actual task.

If studies and researches hold credibility, then such environments should actually reduce the employee productivity instead of increasing it as has been claimed by the proponents of open-space layouts. In fact, it has been proven that people make more mistakes in open-space layout and take almost twice as long to complete a task.

An effective collaboration must increase employee productivity and this will happen if the individuality of team members is maintained. Collaboration through open work spaces takes away the individuality factor and builds group thinking, where the alternate approaches to solutions are overlooked. To put it in Cain’s words, it brings in the new ‘groupthink’ and herd mentality which is detrimental to team work.

So, is productive team collaboration really possible? Yes, it is through collaborating online and building distributed teams with the help of online collaboration platforms – the case that I was talking about earlier!

Un-interrupted and isolated work environments are as important as group meetings and team discussions are, in order to develop productive collaboration. Here comes the glaring need for effective project managers. Project managers must ensure that every team member understands the project goals & purpose and how his/her part is going to contribute to the larger whole.  Once the purpose is clear, individual team members can complete certain tasks on their own. If a problem arises, they can co-ordinate and collaborate keeping focus on the purpose, while exploring various options for the ‘how’ part.

Many online collaboration (or project management) tools encourage organizations to follow distributed work culture for their teams. These collaborative platforms allow collaboration among team members by giving them distance, space and privacy, while permitting tracking independent tasks and overall progress of any project! Space and isolation gives them a chance to reflect upon many pros and cons of a solution before presenting it to the online forum or in an in-person meeting. The team can decide how often to meet and be well on their productive paths without wasting time.

The project manager gets to decide how to allocate tasks and generate tickets. He gets to understand where the project is heading through aggregated information on dashboards and accordingly decide which team members need to meet face-to-face. There is no need to distract everyone.

Needless to say that the online collaboration platforms also reduce the unnecessary travel stress for the employees and reduce capital expenses of the organization for maintaining a large office space.

Are you ready yet?

Why Project Management Tools matter?

March 26, 2012 By Mridula Velagapudi

Leave a comment

You can’t cut your way to growth. Why am I saying this after publishing other pieces such as Cost Cutting Techniques for SMEs? It’s because people tend to flow in a wave (often losing focus on logic) and currently this is exactly what is happening everywhere. It all started with the financial recession in 2008 and is still the buzz of the industry – keep your costs low……cut down your costs….etc. etc.

And talk about startups and SMEs, the web is glut with advice on keeping costs low. It is definitely true that keeping costs under control is the mantra for stopping unnecessary burn. There is only one problem with this though. Entrepreneurs get so much carried away with the ‘reducing cost burn’ thing that they often start considering some important and necessary steps too as needless COSTS!

But mind you, the word here is ‘needless’. The important thing for you to understand and judge is – what is important and what is needless. Objectively speaking, a cost which a startup incurs in initial years may seem needless, as it may not show any direct inflow of revenues. But you need to judge subjectively too. Is it adding enough process efficiency that in the long run will create quality product or service?

SMEs and startups usually get too much into the ‘cost cutting’ approaches to operating and expanding their businesses that they even avoid using certain very important tools such as project management tools. They continue managing things with the spread-sheets. But there are some project management tools which can be used not only for managing software projects but also for tracking work progress and overall business operations with

  • Clients and vendors
  • Internal units
  • Other stakeholders such as affiliates or resellers

The vital aspect is that the features of these project management tools can be customized based on the nature of your business. The idea is to bring in a smooth execution of processes whether it is in SDLC of a software development company or a project which includes procurement-production-delivery-implementation-support cycle of, say, a research/training company.

As an example, let us explore the importance of the ‘dashboard’ feature in these project management tools. Dashboards aggregate and present information in such a way that the project managers get to know the health of a project entirely at one place and at one glance. Dashboards can be applied in multiple areas within the organizations, including monitoring and tracking project status. Thus they can provide you up-to-date view of the current status of your project and help you track progress & milestones of any single team.

Another important feature is email alerts which are generated automatically whenever a ticket is generated or a task is allocated to a team or a group member. All you need to do as a project manager is to ensure that you have invited the group member with appropriate controlled access and defined his role.

These are literally just the two features out of many others which can add efficiency in your business operations by generating a sense of collaboration. Features such as resource management, time sheet, file sharing, wall (for sharing comments and common group announcements) and wiki management that are not worth ignoring. They add that cutting edge to your operations.

Fighting to keep costs down to unreasonable levels may not give you a remarkable growth. It is not sustainable in the long-term. What you need to consider is the use of appropriate tools which can leave more time at your hand for you to be able to think strategically and aim to reinvent the business. Do not learn how to cut costs all the time; learn how to increase revenues by reinventing businesses in the same industries. Embrace intelligent tools and see the difference.

Do you think you should trash that?

 

Classic Mistakes of Software Development and How to Avoid Them

March 21, 2012 By Mridula Velagapudi

1 Comment

Very recently I came across a white paper Software Development’s Classic Mistakes 2008, v1.02, published by Construx, and that prompted me to write this piece. The white paper is based on the responses of 500 software practitioners that were surveyed. Out of the 42 mistakes which Steve McConnell, CEO and Chief Software Engineer at Construx, has listed, I will concentrate on the top 10 mistakes that were reported to have serious to catastrophic impact on software development project.

List #1

This is the list of top 10 mistakes and the percentage of respondents who think these mistakes occur 75% of times or more (Software Development’s Classic Mistakes.  2008. Table 1, pg. 6):

  1. Overly optimistic schedules – 77%
  2. Unrealistic expectations – 73%
  3. Excessive multi-tasking – 71%
  4. Short-changed quality assurance – 70%
  5. Noisy, crowded offices – 69%
  6. Feature creep – 69%
  7. Wishful thinking – 68%
  8. Insufficient risk management – 68%
  9. Confusing estimates with targets – 65%
  10. Omitting necessary tasks from estimates – 61%

List #2

This is the list showing percentage of respondents who think these mistakes have serious to catastrophic impact on project development (Software Development’s Classic Mistakes.  2008. Table 5, pg. 9):

  1. Unrealistic expectations – 83%
  2. Weak personnel – 78%
  3. Overly optimistic schedules – 78%
  4. Wishful thinking – 76%
  5. Short-changed quality assurance – 72%
  6. Inadequate design – 72%
  7. Lack of project sponsorship – 71%
  8. Confusing estimates with targets – 71%
  9. Excessive multi-tasking – 71%
  10. Lack of user involvement – 70%

Item nos. 5, 6, 8, and 10 from list #1 are not in list #2 and hence can be said that they do not have serious impact on software project development.

The point to ponder is that if these are the mistakes which occur most frequently and also have serious impact on software development, then why are these mistakes occurring in the first place? And if these are frequently occurring then in most of the cases the outcome of the mistakes should be predictable and hence their impact on software development should be controllable. But I guess this is not so.

Most of the time this must not be feasible because in every project there can be new challenges and coupled with the inexperienced personnel working (no single person can have experience in every sphere while he is still in his career stage!), it can lead to assumptions based on past projects. Basing assumptions on past projects by itself is one of the deadly sins of software estimation in SDLC. So, how do we control this?

On closer analysis, you will see that most of these mistakes which are indicated to have serious to catastrophic impact arise during the requirements gathering and estimation phase of an SDLC. This could be attributed to many reasons such as:

  1. Improper selection of SDLC Management tool. Your SLDC management tool may not have provisions to involve the end-user or the stakeholders
  2. Improper selection of SLDC model. The SLDC model selected may not have the provision for continuous requirements gathering or short iterative development stages as a part of that SDLC’s methodology.

Evolving requirements throughout the development cycle and concentrating on short delivery cycles can be one solution which may promise to minimize the possibility of these mistakes occurring. This helps both the stakeholders as well as the developers because even the stake holders can understand their requirements better as their business progresses and the developers get to accommodate fluid requirements gathering process right from the beginning. This can take care of items 1 to 10 in the list #2, excluding item #7.

Budget constraints (indicated by item #7 in list #2) can be a big hurdle for the satisfactory progress of a project. To tackle the budgetary part, it is encouraged that the businesses consider the cloud models of SDLC management tools.

Overall it boils down to this – in order to minimize the impact of the software development mistakes, it is encouraged to:

  1. Select SDLC models which offer agility
  2. Select SDLC Management tools that have automation and intelligence integrated. These aspects support developer productivity by reducing the time spent by the developers on mundane tasks, and hence does not render them unproductive or inexperienced.
  3. Select SDLC Management tools in the cloud

What is your take? Can you suggest more tips?