-- Challenges of Project Managing & Agile Methodologies --

Although these two subjects could be seen as two different topics (and they are),  they are intimate related and therefore I decided to cover both of them on the same paper. In my personal opinion Agile surges as a solution to the drastic increase of many Information System Development (ISD) projects failures.  However rather that analyzing the failures and correcting them, we decided to re-invent the wheel.

Let me explain, for a project to be successful there are few elements that are needed, you need the resources (people), they need to have the technical knowledge adequate to be able to develop the solution, you need a problem or requirements (what is needed, what is the problem that I am trying to solve), you need a solution or solutions (how I am going to resolve of mitigate the issue),  and you need a plan to get there.

 I learned earlier in my career that the most important elements on Developing information system are

1.- You need to have a clear understanding of what is that you are trying to solve.
2.- You need to understand how the proposed solution will solve the problem.
3.- You need to have a fix scope of what is that you are going to do, and make the business sign on it.

It is often that software engineers don't understand the problem (many times because the business do not understand it either, and provides very vague description and requirements). I find often that the issue here is the technological gap in communication. Depending who is the person from the business that you are getting the requirements from that person will be able to provide the exact requirements needed or will just give you a vague idea, which will likely translate in a poor design that does not meet the business requirements.

Many times business owners wants to set deadlines that are just not feasible, and developers need to compromise in the quality or their programs in order to meet the deadline, which end creating production issues. Another typical issue is that due to the constants business changes the scope of the project is changing all the time. So basically if you spend time understanding the requirements, you have solid knowledge of the technology that you will use for the development, you have a clear scope of the project,  your deadlines are feasible and you have a project manager supporting you, then you have a project that have a very high percentage of success rate.

Another challenge that was introduced in the last 10 years is that a big portion of the development projects are outsourced overseas, with this the communication issue that I explained above gets exponentially worse. The other problem that is difficult to solve is the constant changing requirements, and that is where Agile plays a role, the idea behind agile is to create a virtual team that will be able to address the constant changes on the fly, what Agile provides as well is a series of micro managing tools that ensure the project is on track before is too late.

Agile in theory looks good, however I have not seeing a lot of adoption on it, and the degree of success of Agile projects vs non-agile projects is still to be proven. At this point you may be asking yourself, if we do not use Agile how else can we close this gap, what other methodology can we use, to what I will answer that it depends of each business and organization needs, there is not a single solution that fixes all the problems.

Regarding to what would I propose for a project where the scope is constantly changing, my answer would be to have additional development groups that will start new development at the tail ending of the other, in that way you can take in production a complete project and you are already working on a new version.

-- The Future of Enterprise Applications --

Like any other technology "Enterprise Applications" surged from a need, initially companies were trying to resolve very specific problems.  Initially there were MRP. (Material Requirement Planning) systems (1970) that intended to aid in accomplish tasks such as schedule production. Later on that need evolved in good part because companies saw the capabilities of the technology and how it turned over time more efficient and more cost effective, the second wave of enterprise systems is constituted by what is call MRP. II  (Manufacturing Resource Planning) Systems (1980), these application not only focused exclusively in production data, but exploded the relationships with Marketing and Finance data between others. Later in 1990 these systems evolved once more into what is noways called ERP. or Enterprise Resource Planning.

As you can imagine by the word Enterprise the idea behind is to integrate in an orchestrated way all business functions with the goal of improving operations, some key features that characterize these applications are.

• Global Scale.
• Focus in Collaboration and Product Strategy.
• Based on a particular business model.
• Aims to adapt and correct based on the markets conditions.
• Leverage business intelligence  and analytic techniques.
• Integrated Information Exchange.

So what is next in the ERP arena?. Well to start with we are in the era of mobility (access your data any time any where from any device).  Mobility will not only add  convenience to Enterprise Systems but also will add a new level of real time data. But what do we need for that to happen, well there is an implicit cost in all these systems, so how do you manage this cost?.

The answer is to use SAS. (Software as a Service) which is usually stored in the cloud where you pay a fraction of the cost or (pay per use). So why this has not taken off?

Below are some of the few reasons:

•    Hesitant due to security.     
•    Technology not being totally there.       
•    Scalability.      
•     Interdependence, could  not exist without supporting range of other services.

What can you do to mitigate the risks

•  You need to build fault tolerance infrastructure or hire a third party vendor that offers this.
•  You need to plan for it instead of stay away from it..