Sunday, May 25, 2008

Re-positioning Issue

A question on re-positioning of a firm, as it "changes" its offerings / services;

http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3176

Tuesday, May 20, 2008

Application Outsourcing - Few Questions

It is not a new topic, and much has already been written on this topic. I'm also writing a hand-book on this topic, where I have tried to cover the topic by bifurcating it into two, i.e. Customer and Vendor.

The customer aspect would detail the activities, analysis, and decisions that a customer has to make even prior to starting discussion with vendor. The reason being, the discussions come much later; first, they do some "house keeping" in terms of "evaluation of needs", and vendor short listing.

The vendor aspect would cover the details on activities, and analysis with respect to "work on hand", the client needs vis-à-vis identified work, the understanding of objectives, current state, and "to be in" state. Of course, the analysis on internal processes with regard to compatibility, and customization and on count of capacity is also necessary.

Since I cannot put the complete contents of the book over here; therefore, to start with, I will provide some background on AO, leading to evaluation of claims of vendors' in this aspect, and finally, concluding it with some questions to think it over. I'm deliberately not covering the vendor aspect, as I believe that should be left to explore (though I would cover in my hand book).

What is it?

Like any other outsourcing deals, application outsourcing also deals with “transferring” the part / complete responsibility of operations to third party. Please note that it is transferring of responsibility alone, and not ownership or accountability.


The scope of the application outsourcing is generally limited to software business applications, which could again be complete or partial. Therefore, it differs from business process, knowledge process, and infrastructure outsourcing in terms of scope domain (if I may call so), otherwise the fundamental principle of outsourcing does not change as such.

Why Do Customer Outsource?

There are various reasons and many literatures on this subject have sited those reasons, like,
1) Strategic initiative
2) Cost Reduction
3) Non-core area of business
4) Innovation
5) Better alignment between IT and business needs, etc.

However, I personally believe there is only one reason for any outsourcing activity, in any sphere, i.e. improvement / betterment. What it essentially means is that any outsourcing deal must result in improvement, which could be (more the better);
1) Reduction in costs
2) Reduction in cycle time
3) Improvement in Quality
4) Accessibility to qualified resources
5) Redeployment of employee in more core / critical areasAbility to “match” business cycles, i.e. faster and efficient ramp-up / down etc.

What it also means is that maintaining a status-quo is NOT enough.

Phases of Outsourcing

If someone were to outsource, one needs to go through phases before realization of benefits. In addition, the benefit "score" would be directly proportional to one's understanding of outsourcing need, and alignment of processes, resources, governance etc. as per needs. Now, without describing it further and elaborating on each phase, let me list down the phases (of course, I will be detailing those in my book);

1) Planning
2) Transition (considering “Knowledge Transfer” as part of it)
3) Steady State
4) Transformation

Vendor's Marketing Information

Again, to save space (and time) I will cover few aspects, which most of the vendors have in their AO marketing capabilities;

1) "More Than Cost Savings Alone",

2) "Application of Innovative Processes"

3) "Application Modernization with SOA, Mashups etc."

4) "Association as Business Partners"

5) "Accessibility to Skilled Resource Pool"

6) "Multi shore capability" ...........

Now, any curious soul would be able to analyze that all points but point #1, i.e. if a vendor meets all points but #1, it will be of no use. Therefore, it is in our interest to not to trivialize the importance of points #1.

The next two points, i.e. #2 and #3, those are an integral part of "Transformation" phase; therefore, the differentiation would be one's understanding of client's process and application of technology and re-defined processes to suit the business needs of the customer. The reason being SOA, Mashups and like, should be seen as the tools available for transformation, along with others. What fits the best for a given customer is not dependent on technology, as technology is only a facilitator.

Therefore, knowledge and expertise in given technology can be an added advantage (may be a differentiator too) to go with a particular vendor; however, the advantage is more governed by business needs, and not by technology alone.

The next point stresses on the need to work together to increase the value creation. Now, one should look for the "offerings", i.e. what is that vendor has to offer, or had been offering, that would result in this kind of relationship, and has not been offered by others. Similarly, has the vendor defined the changes / support procedures / activities / tasks that you as a client should be doing to foster the "partner" relationship. And, more importantly are those acceptable to you, and do not jeopardize your business values / advantages etc.

Availability of large skills is definitely advantageous; however, does that also provides the easy flexibility to absorb the business fluctuations, i.e. ramp-up / down? Do those skills are relevant to you? Do those match your "planned" cost structure? Do those skills are available where those were required, i.e. "shore" availability? These and many more of like these, are the questions that one must ask and answer to truly assess the "value" of these "capabilities".

The Party Pooper - These capabilities are no longer the differentiators, as almost all "matured" vendors provide these capabilities, and more importantly, these have become the threshold for selection, as almost all client's look for these capabilities (I'm not counting client's with "small" needs in this category). Therefore, the mentioned capabilities in themselves are not differentiators anymore, instead, it is the application of those capabilities, which differentiates one from other.

The last section of this write-up "Self Introspection" poses some questions to you; try answering those questions without any prejudice. I'm sure you will be surprised with your findings, "before" and "after". In addition, you will also find the ambiguities in needs / goals / actions of clients and vendors alike.

Customer - Gather Information ON;

1) What is the competency level of the vendor in outsourcing; their track record, and if possible, reference(s)?

2) What are the support models a vendor has to offer?

3) What are the pricing models that are applicable for given work?

4) What are the infrastructure requirements to support it?

5) What are the governance models, and associated costs?

6) What are the synergies between vendor and client?

7) What is the transition time a vendor is committed to?

8) What are requirements from resource perspective?

9) What are transformation policies / processes?

10) Existing customer referrals

11) Security policies and implementation (physical, data, confidentiality etc.)

12) SLA currently supported (operational efficiency and effectiveness vs. business value proposition)

13) Work ethics policies and implementation level

14) Infrastructure – within center of operation and with city / country of destination

15) Financial verification?

16) Recruitment process

17) Risks?

The answer to these questions would provide you data points to evaluate vendors “fit” to your requirements. Please remember this is a preliminary scrutiny, wherein, you are trying to establish the “interest” in vendors, i.e. you are “short-listing” the vendors, whom you would be interested in doing business with. Therefore, at this stage you do not have to defend, look for a solution, or prepare for negotiation, as that would follow. For example, a competency check on a vendor itself may further explode into close to fifteen (15) questions!!

Self Introspection

1) What is true differentiation; technology, processes, or resources?

2) If "Sales" is product / services focused, and "Marketing" is customer focused, then why is it that we have only Sales persons in a customer deal, especially in AO, where there is no direct and readily applicable solution?

3) Technology, and processes can be copied, and invariably are copied over a period of time, and personnel are hired (at competitor's expense), still some companies are able to differentiate, how?

4) It is being said that client's focus from immediate "cost" gains, has changed over a period of time; why is it so, invariably the deals last leg revolve around price "bargains"?

5) What is that a vendor can provide in addition to cost reduction (by lower price) that would be of interest to customer, and would also help the vendor?

6) Philippines, Eastern Europe and former USSR countries are seen as viable alternatives to India, and China; in this context, how far the claim that customer's are looking beyond reduced price, holds true?

7) What are the instruments available to a vendor / customer to increase the "value" of the deal, so that negotiations are being carried out beyond "price bargains"?

8) An AO deal can be multi-geography and multi-vendor proposition; how does one govern it? What is best governance mode and order in this case?

9) How does one define the SLA in absence of any historical data? Can it be entirely based on client needs, and / or vendor's maturity / capability? OR, can there be some "intermediate" stage, along with more than one solution approaches?

10) Client does not like T&M kind of pricing, and vendor would like to avoid FFP kind of pricing; what is the best pricing model for AO deal? Can it be standardized for all AO deals?

11) It is being said that client and vendor should act as business partners to maximize the benefits of a deal; what prohibits them to act as business partners? Can those differences be converted into synergies?

12) AO deals runs for years together; what are the elements, which can impact the deal, OR in other words, what are the attributes that one should cater to, in order to increase the "predictability"?

The above questions would lead you to answer some of critical questions that both (vendor and client) the entities should be attempting for any AO deal, i.e. "What are things (activities, data gathering and analysis) a vendor and client should be doing, prior, and during an AO deal?".

Friday, May 16, 2008

PMO - What is it?

A Project Management Office (PMO) is an entity that defines, and maintains the processes related to Project Management in an organization.

The above given definition is very simplistic, and does not cover the complete scope of PMO. First, the way I look at it, I consider it as a Program Management Office, and not Project Management Office. Second, I consider scope of PMO is not confined to definition and maintenance of processes; instead it should also include facilitation, implementation, enforcement, evaluation and improvement. Therefore, I would rather define it as, "A Program Management Office is an entity that defines, maintains, facilitates, implements, enforces, evaluates, and improves processes and activities, required to run programs / projects effectively within given constraints".

Having said that let me enlist the activities that a PMO should be doing;

a) Program Management - All processes and activities that will help alignment of projects with organization strategy, i.e. prioritization, portfolio creation, resource allocation, implementation and support, along with all other attributes, as defined in the definition of PMO.

b) Portfolio Management - Establish a portfolio of projects as per priority, and assign resources to execute and manage the portfolio.

c) Project Management Processes / Methodologies / Activities - Define, Maintain, Facilitate, Implement, Enforce, Evaluate, and Improve processes and methodologies.

d) Training - Support, guide, and train project managers in executing the projects. Provide necessary training, through identification of needs of the individual and organization.

e) Infrastructure - Investigate, pilot, and institutionalize necessary tools and methods required for effective program management.

f) Governance - Provide necessary guidelines, support, facilities and services to govern the programs / projects from set principles, objectives, and goals perspective.

g) Implementation - Decide whether you want it to be either "Consulting" or "Centralized" kind of structure. Formulate your plans and execution as per structure needs.

h) What better to govern a Program than "Benefit Relaization"? The reason being,
1) It provides the required focus,
2) Helps in optimal allocation of resources, and
3) Reduces the risk of faliure.

The last point is important because, one seldom selects a program on the basis of ROI alone. As the ROI presents the immediate / potential "financial" gain or loss. However, an organization needs to look beyond "Financial Measures"; therefore, it is imeperative for an organization to include other factors too, like, market, competitor, customer, internal processes, environment etc.

Yes, you may argue that those are subjective factors; however, those are critical influencing factors. All these factors would have an affect on an organization's current and / or future capability; hence, would need a due consideration during selection process.

Though, this analysis is originally proposed by McFarlan, from IT application's investment perspective. However, it can very well be extended to this scenario, i.e. assessing the impact of the program on organization's capability (current vis-a-vis future).

Current (High) / Future (High) - It is stratgeic investment, and has to be taken up.
Current (High) / Future (Low) - It is critical for survival / current position maintenance.
Current (Low) / Future (High) - It is critical for organization's future standing; may help in turning around the company's future.
Current (Low) / Future (Low) - Low impact on current and future capability; a no brainer.


It is true that how a PMO should be structured, is a call that any organization has to take; however, it should be in line with organization needs, as each structure has its own merits and demerits. Similarly, an organization cannot afford to choose only one or few of mentioned aspects of PMO, provided they understand, and are sincere about PMO.

The previous sentence may sound harsh; however, it is true that there are many organizations where PMO's responsibilities have been confined to "servicing" PM resource requests. Unfortunately, even that is not diligently. In few other cases, it is confined to "audits" alone; however, the PMO responsibility should be visualized more from a governance, rather than audit / compliance perspective.

To summarize, one should understand what PMO is NOT;

1) It is NOT an entity to service PM resource requests; it can be handled by resource team, or should be one of other activities, and should not be the only activity.

2) It is NOT meant to do audits, you have many other ways to do that; instead, focus on governance.

3) PMO is NO longer a "Project Management Office"; it should rather be seen as "Program Management Office".

4) It may have overlapping responsibilities with other support groups; however, under NO circumstances it can delegate those responsibilities to those groups when it come "Project Management" resources. For example, Training and Resourcing are the activities usually managed by "Learning" and "Human Resources" entities; however, in case of PM resources, PMO has to work with support groups to get it done.

5) PMO CANNOT just either be a defining, facilitating, implementing, governing, or managing entity; instead, it has do all those activities, together.

6) It should NOT be a one time activity; instead, it should be an on going, and continuously improving activity.

7) It CANNOT either be an administrative or bureaucratic entity alone; as suggested, it has flavor of both. However, it has much more to perform than activities around these two attributes alone.

8) Certification or no certification is an individual opinion; however, certification cannot be a "guarantee" for expertise.

Therefore, the success of PMO depends on top management's understanding, and seriousness. If they have understood it correctly, from its scope, benefits, and responsibilities perspective, I do not see any reason as why it would not deliver the results for which it had been constituted.

PMO Evaluation

As true for any process, unit, entity, or methodology, we need to ensure that the PMO is performing. So, how do we measure the performance of a PMO? I personally feel that a PMO should be evaluated against following parameters;

1) Program's alignment with organizational strategy, and its contribution.
2) Program / Project performance against budget / cost, benefits, and schedule.
3) Overall customer satisfaction (across projects).
4) Improvement as compare to previous year (cost, cycle time, quality, service etc.).
5) Skills development (of resources)
6) Maturity from predictability of capability perspective.

Tuesday, May 13, 2008

Governing Vendor's Work

I had come across a situation wherein I was asked by a person that his organization do not actually build the product, or execute projects end to end, instead it is done by vendors. The vendors come with their project managers and all other development, QA resources, and they follow usually their standards; they end up following their way in managing project. In nutshell, their (client) only job is to supervise vendor's work. The questions is how to ensure that project is managed in a best possible way under this scenario.

The way I see it, they have already passed the state of "Vendor Assessment" for contractual award, and it had more to do with their "performance assessment"; let's concentrate on the "performance" evaluation part alone.

It is true that you will only be able to assess the performance if you are clear on goal(s). If you know what you need to achieve, and the purpose of hiring contractors instead of building that internally, you will also know the attributes to assess their performance.

In addition, making (or seeing) vendor as partners is good; however, relying on them completely may not be in your best of interests. Please note that by choosing the alternative of getting it done through vendors, you have only passed on the responsibility; the accountability still lies with you.

What it essentially means, you need to identify the attributes from your list of objectives and goals, which are critical for your success, and need to measure / assess the vendor's performance against those attributes. In "service" parlance those are termed as "Service Level Agreements (SLA)". That is, you need to identify the service levels that you require / expect from Delivery, Quality, Time, Cost, Cycle Time, Productivity, System Availability, Performance, Disaster Recovery, Business Continuity etc.

That is, all attributes which affects your business and which you would like to control for favorable business results.

Now, what attributes will constitute SLA, will depend on nature of assignment / relationship with vendor, i.e. whether its Development, Engineering, Maintenance, Application Outsourcing, Business Process Outsourcing, Voice related services outsourcing, Infrastructure Outsourcing etc. Given the context, you would have SLA tuned to that situation.

Please note that outsourcing does not mean you have to follow what vendor says; instead outsourcing warrants more focused (and may be stringent) governance, i.e. governance on all aspects (Finance, Delivery, Quality, Resource Skills, Productivity, etc.).

If a client decides to outsource, it means there would be situations where it would be saving costs; however, at the same time there would be situations where it would be incurring costs. Moreover, there would be some one time and some recurring costs and savings; for example, it would be incurring following onetime costs;
a. Legal Fee
b. Transition Costs
c. Severance Package (if ends the contract prematurely)

On the other hand in a long-term event, it would be having costs / savings and accrual on a recurring basis;
a. Budget Savings
b. Facilities and other savings
c. Training Costs and Staff Turnover
d. Staff Augmentation
e. Inefficient Business Operations – temporary and short-period; after that it should improve. That is cost initially and savings later.
f. Governance cost, etc.

To summarize, identify your objectives and goals, identify measurements for those objectives / goals, set minimum acceptable levels against those measurements (your SLA), decide on incentives for improved results, and make vendor work towards your objectives and goals. Further, if you really want to analyze the perfromance, then you should also consider of comparing the cost of peforming a work internally vis-a-vis getting it done through vendors.

Sample Metrics

Process

1) Variances - Schedule, Effort, Cost
2) SPAN - The elapsed duration since original baseline
3) In process metrics - EV metrics
4) Productivity
5) Cost of Quality (CoQ)
6) Efficiency - Review / Test
7) Effectiveness - Review / Test / Internal / External

Product

1) Defect Density
2) Defect Slip-Age
3) Field Errors

Metrics for Self (Customer)

1) Requirements Stability Index

Monday, May 12, 2008

Micro Management

This (micro management) is not new; one time or other either we personally have gone through, have seen that happening to others, or worse, had been doing that knowingly (or unknowingly).

Let’s straight away try to list out the reasons for this skewed behavior, detail those reasons, and finally try to uncover the remedial steps.

I personally believe, there are two reasons for this skewed behavior;
1) Inferiority / Superiority Complex
2) Failure to understand the preparedness level of employee

As you must have noticed the “fear of loosing” is imbibed into first reason. A person with inferiority complex would resort to micro management either because of threat to his / her existence, threat to potential gains, or threat to his / her growth. In either case, he / she is insecured about his / her well being.

An opposite of it, a person who is either a perfectionist or an exceptional performer, is insecured because of his / her reputation. A reputation that he / she has built over a period of time, and the standards that he / she has created for himself / herself.

The problem is even if they were not so hard on themselves, and would want to provide some leeway to others to perform; however, people around them have certain set expectations for “standard” for any given task / work. It is obvious that anything less than the set standard will be considered as “let down” by others, which ultimately may jeopardize their reputation, and hence, growth path.

As evident, either way, whenever there is a situation of “fear / insecurity”, people end up doing micro management. Therefore, if we need to address “micro management”, we need to address the “fear / insecurity”; the first reason of micro management.

Now, let me explain my second reason, i.e. the failure to understand the preparedness level. As we know, a management style is dependent on the preparedness level of an individual. It can range from being authoritative / directional, guidance, supportive to delegation. One may have a pre dominant style; however, one can not have single style for sure. In addition, I personally believe, even the pre-dominant style is a reflection of preparedness of his subordinates and not entirely his (provided there is no “fear”).

The reason being, a style become pre-dominant because he / she has to use that style, repeatedly, to get the things / tasks done. Otherwise, if he had a mix of direct reports, i.e. with varied preparedness levels, he would have definitely made use of style, as applicable to given preparedness level. The reason being, failure to read / understand the preparedness level leads to subordinate dissatisfaction, as it would lead to perception of micro management.

Now, let’ see how we can improve the situation by doing things a little differently. First, in order to improve the “situations” because of “fear”, one should,
1) Communicate – provide necessary and sufficient details periodically. This would help you in gaining the confidence of the person, as you would be helping the person in knowing the “unknown”.
2) Build trust through actions – do away with office politics, and be loyal to your work.
3) Set the expectations right – do not be hard on yourself and your reports because of wrong perceptions / expectations set by others.
4) Understand that there is always a probability of exception; therefore, work with the exceptions.

The second situation demands / needs a thorough introspection from manager himself / herself. He / She needs to identify the preparedness levels of his / her reports, and adapt his / her style as per preparedness level.

The suggested steps may sound trivial, however, those are the ways to reduce the instances of micro management. In addition, those may sound trivial, however, their application is not as trivial as it sounds.

Friday, May 9, 2008

Mintzberg Framework of Managerial Roles

Three important sub-roles that would apply to a Project Manager role.
-- Importance

-- Consequences of neglect



A skill set that is required for a given manager depends upon the level of operation, i.e. at what level he / she is operating in organization hierarchy, and hence what skills he / she should be having, i.e. technical, human or conceptual.

Each manager’s job involves various functions of management, i.e. planning, organizing, directing, and controlling. These functions are goal-directed, interrelated and interdependent. Planning involves devising a systematic process for attaining the goals of the organization, which in turn would prepare the organization for the future. Organizing involves arranging the necessary resources and infrastructure to carry out the plan. It is the process of creating structure, establishing relationships, and allocating resources to accomplish the goals of the organization. Directing involves providing guidance, leadership, and overseeing of employees to achieve organizational goals. Controlling involves verification of actual performance with respect to planned one, such that if actual results do not match the plan, corrective action could be taken.

Therefore, a manager’s role could be summarized as,

-- Planning
-- Organizing
-- Directing
-- Controlling

As evident from above diagram, importance of each role could not be diminished in comparison with others. Because, these roles / activities are complementary by nature rather than being supplementary to each other.

Now, if we look at Mintzberg’s framework in light of these activities, we shall find that those also highlight / emphasize on these attributes.

If a person’s role calls for accountability on account of all delivery aspects of a project, process improvement and resource management, and as a Delivery Manager, person’s responsibilities are more towards pre-sales, client interaction and presentation, resource management and project delivery. In this case if a person were to choose only three roles, then those would be,
1) Leader,
2) Monitor, and
3) Entrepreneur.

As person will be directly responsible for project’s execution and delivery; it would suicidal for him / her if he / she does not keep track or monitor the progress of project. One has to plan, organize, execute and monitor the progress at every stage / phase of the project. One has to compare analyze and take corrective actions on the basis of results drawn from that analysis. One has to disseminate the information to all support / affected groups / stake holders and maintain communication / contact on a continuous basis.

The reason being, if the link of communication is broken then it would have an adverse impact on the progress of the project. As in that scenario, in the absence of effective monitoring communication channel will break and the elements of project would not be in sync with others. This may also lead to further chaos, as either people might not be aware of their task(s) responsibilities or might be waiting for completion of parent activity.

But, if we have effective monitoring and tracking process in place, these hurdles are addressed effectively. As under those conditions, people / stakeholders will have access to the “information”, which is so critical to the success of the project. Therefore, monitoring is an essential and critical activity that a person’s role identifies / demands.

Now, a fair introspection at person’s end would reveal that, for the success of a project one needs to have right resources, i.e. who have requisite skills, have undergone needed training, and have fair amount of motivation to do the assigned task.

But the question is how will he / she identify their needs with respect to training, emotion, comfort, security, development etc., unless he / she interacts with them and try to understand their needs. The reason being if they do not have the comfortable feeling when they work with the person, they will not share their feelings, thoughts, ideas, problems, and solutions with him / her. Therefore, under those circumstances it is required of him / her to understand their needs and provide them the necessary support to satisfy those.

However, is it really sufficient to understand and satisfy the needs of people / resources, in order to achieve success in a project? I’d say no, because any demand without matching responsibility would create an imbalance, which would prove counter productive to the goal.

Therefore, one needs to define their responsibilities, provide guidance in achieving the set objectives, provide communication with respect to responsibility, business, growth, development and all other aspects, which have influence on the working ability, capability and willingness. How, much of each (or some) should be a part for a given person, depends on the person, hence cannot be generalized.

Moreover, it is a fact that in a crisis situation or hour of need, people seek for help to those, who are in a position to help. That is, who could guide them and provide the needed help to bail out of that crisis / situation.

Now, imagine a scenario, where he / she fails to understand all of these attributes, and fail to take any action on those; will his / her resources be satisfied, will they be able to complete the work, will that be of desirable / expected quality, will that be under committed time, will relations with that resource be without any strain, will the resources be willing to work with me on next project, will he / she not bad mouth about him / her? All these and many more questions would need to be answered to fully understand the implications of the same.

Therefore, it is imperative on his / her part to provide them all these attributes and keep improving on these so that they also improve their expectation from themselves.

Last but not the least, entrepreneurship. If we look at the responsibilities defined by this role, those could be summarized as,
1) Initiate improvement projects,
2) Identify new ideas, and
3) Delegate.

These responsibilities / activities make sense as the environment under which we operate, is under continuous change. And, there are two ways to adapt to these changes, first, we initiate the change and then adopt / institutionalize the same. Second, we react to the change, i.e. we change ourselves to adapt to changed environment.

The first one is more dependent on the pro-active part of an individual and he / she has the option either to start it or wait for it. However, in second case, he / she does not have a choice, one has to adapt to changing environment, otherwise the environmental forces would make the person / process / context element obsolete.

Similarly, in a software field, if one does not de-skill and re-skill, improve upon existing process and technology, improve upon existing norms, one would find himself / herself in a position, where either he / she should either quit the field or adapt oneself to changed environment.

As mentioned earlier, either we can initiate or adapt, however, in both cases we have to change to survive.

Now, coming back to person’s roles and responsibilities, if he / she have to make a choice, he / she would definitely choose the first option. The reason being cost of adaptation is more than initiating a change. Again, the same can be understood from a set of questions, i.e. what if I do not improve upon existing technology / processes / norms, will the market be same, i.e. with respect to demand, supply, competition, technology, environment, and so on. If the answer to any of these questions is NO (and threatening for the first one), it suggests that one cannot escape the change.

But can one do all the related activities by himself / herself? Am I self sufficient to carry out those activities? May be not, but if I am self-reliant to carry out those activities, probably yes. This probability of “yes” makes the difference. Therefore, one has to constantly think about reducing defects, improve productivity, reduce human intervention, raise the norms, enhancing customer satisfaction, reducing span and so on.

The reason behind this “change” could be the fear of survival; however, it brings out the best out of each involved in this activity.

As evident and explained, all activities required for planning, organizing, directing and controlling are necessary, and one cannot choose one at the expense of another, however, the degree of criticality changes along with the role, as has been explained above with respect to a person’s role.

Marketing - A simplistic description

The marketing concept aligns itself towards satisfaction of needs and influencing of wants of customers. If we look in depth the concept of marketing, we would realize that marketing isn’t just a concept; instead it’s a practice, which revolves around customer. In other words its customer centric approach, where whole gamut of activities revolve around customer.

One can argue that it depends upon the approach that we take towards marketing, i.e. whether it’s a “Product Oriented”, “Sales Oriented” or “Customer / Market Oriented”. However, in first tow approaches the emphasis is on “selling” and not “addressing” the customer wants. Those approaches might have succeed in a “closed” economy, where consumers do not have many options and have to live with the available products, pre 1990 India and old USSR are the examples of those approaches. Under both, consumer did not have a choice and it was a supplier’s market, where the demand exceeded supply.

However, in current market driven economy, the focus has shifted from supplier to buyer. If that is the case, then the marketing focus should also shift towards customer, because ultimately market is nothing but the demand of customers (assuming the suppliers are already there). And we need to align our efforts in such a way that we are able to address the customer wants fast, efficiently and effectively.

Therefore, the marketing is,
a) Orientation towards customer / Customer focus
b) Adaptation, instead of “Selling”
c) Seek information, technology, needs, competition (global / local), markets, products
d) Coordination of activities, departments units
e) Continuous feedback via probing, surveys, research, analysis etc.
f) Seeking new opportunities
g) Seek, deploy and hone best practices
h) Focused market servicing (segmentation based on demography, income level etc.)
i) Brand building, with respect to quality, customer care, social obligation, value add etc,
j) Understanding of customer needs, wants and demands.

If we look at the above stated points we’ll find that each and every single point, directly or indirectly touches the customer. Today the market is driven through customer, and if we do not pay attention to customer needs, it is obvious the product that we develop may be a technological marvel, but would fail in the market. And it is not limited to a product alone, it holds true for service, people, good or any kind of “thing” which requires transaction.

As the ultimate objective for any business is to make some profit, so that its economically viable to be at that place. However, before, making a decision about what would be our product (assuming that he / she decides to develop one product), would that not be appropriate to find out the market for the same? But, who drives the market? It is obvious that market is driven by customers. The reason being if they are not there, how would the transaction happen? Can we imagine a scenario where we have a market without a customer?

Well, if the customer is so important to a business, then it is obvious that we can’t ignore him. This is what Donald E. Peterson had remarked. If we have not addressed the needs of our customers or did not think about customers needs in our production process, then we will end up with a product, which will have no market value. For example, customer market that Ford is catering to is service class with limited means of income. Their primary objective of buying a vehicle could be,
1) Cheap transportation
2) Safety
3) Reliability
4) Low Maintenance Cost, and
5) Relative comfort

So, if a customer is looking for these attributes, then there is no point in creating a car driven around by “James Bond”. On the other hand if we address these needs and “add” some features, which are of some benefit to the customer (after probing, research, past experience, analysis etc.) then it would also cater to the “delight” need of customers.

The above explanation captures only first interaction and need, what about servicing, trouble shooting, relationship building? The customer should get a feeling that whenever he / she needs any help with regard to purchased vehicle; Ford is there for me to help. If Ford is able build that comfort and confidence in its customers then it is able to get a little more closer to the customer and it’s end objective of higher markets share, sales and profit.

The cycle would be complete when we seek, adapt, deploy, hone and control our activities / strategies in such a way that every cycle brings us closer to the customer needs and hence market.

Thursday, May 8, 2008

Managing Projects in a Complex Environment

The following text was my response to a post @ allpm.com with regard to "Managing Projects in a Complex Environment".

The person had identified a complex project having one or more of following attributes;

- Multiple project sub-components (complex project structure)
- Multiple resource pools (complex organisational structure)
- Multiple skillsets / disciplines (complex project target)
- Multiple sites - Multiple cultures / countries
- Multiple organisations (partnerships, co-developments)
- Multiple suppliers - Multiple customers

Response

Your observations / details on complexity are indeed practical and I completely agree with those observations.

Having agreed to what you have already detailed; I personally believe primarily the "complexity" has got introduced because of;
a) Dependency
b) Cultural differences
c) Time zone differences
d) Uncertainty, if I discount the skill shortage / mismatch, and size of resource pools for the time being.

Since there are multiple stakeholders, with varying (and sometime conflicting) interests, varying maturity levels, and may also have dependency on others for them to succeed, it would be impossible for any single entity to succeed without making other(s) succeed. The reason being, even if you complete your task / fulfill your commitments, the end result / outcome would still be eluding the program / project, if others fail to deliver.

The cultural differences and differences in time zones further aggravate the situation, as we have a situation where we have to deal with "emotional" challenges; and time zone differences would not be conducive in resolving those faster.

All these factors would lead to increased level of uncertainty; leading to increased complexity. Therefore, if we are able to bring down the level of uncertainty, I personally believe, we would also be able to bring down the complexity (under sighted scenario).

How do we do that? My analysis suggests that under these kind of situations, everything boils down to governance. The reason being, the followed engineering process and standards will be uniform across the program / project, and stakeholders; therefore, engineering is not the place, which needs the maximum attention. Instead, it is the governance, which needs your attention, under these scenarios.

For example, suppose I take the same example as sighted by you, however, modify it by this bit of information, i.e. “the program / project is being done by a single entity (read as vendor), however, through multiple delivery centers, spread across the world”.

Now, you would appreciate that though the single entity did not have the dependency on external (other) vendors, still it has to deal with cultural and time differences, dependency, and hence uncertainty. What essentially, I'm trying to bring out from this modification is the fact that the uncertainty is not because of multiple stakeholders, or engineering processes, instead it has been there because of dependency and cultural and time zone differences. The engineering processes can be standardized (and had already been) and everyone can be made to follow, however, the "soft" aspects would need something more than that.

I personally believe under these kind of situations, a formal, framework driven governance works the best. That is, you need to define the three attributes, namely, "Structure", "Functions", and "Practices".

What it essentially means is that you need to define, roles, descriptions, responsibilities, accountability to primary stakeholders / shareholders, values to be carried out etc., i.e. the "Structure" for your governance. How many levels within that, it all depends on the "need" of the program / project. Next you define the "What", i.e. what needs to be accomplished through governance when it comes to Finance, Risk, Delivery, Quality, Benefits, Resources, Issues etc., i.e. the "Functions" of your governance. Finally, you need to lay down the execution plans, i.e. "How", to achieve the "Whats", this will cover the "Practices" part of governance.

No doubt, it will increase you governance cost; however, with varying capabilities, and interests, what is another way to secure their commitments and cooperation? Therefore, if you have the governance in place, then it would be easy to track, monitor, and control.

Lastly, the two discounted items, i.e. number of resources and their skill sets. As you can see tackling those will not be as difficult as those would be part of your governance. Every stakeholder needs to define the needs and maturity (and preparedness) of the resources required for given task, and work towards fulfillment of that. The reason being, if they don't, they will miss on their targets / SLAs.

To summarize, a well laid out and functioning governance will help you in reducing the uncertainty and hence surprises under given scenario; which, in turn will provide positive push to given program / project. Further, the visibility to information within program / project can be increased (thereby reducing the uncertainty) by dashboard driven information dissemination. The structure of dashboard will depend upon the program needs; however, one in line with “Balanced Scorecard” will definitely be preferable. As this way of communication will bring out the “Advanced / Early Warnings”, to help you in substantially reducing the “reactive” executions.

http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3081

Several Real World PM Issues

The following text was my response to a post @ allpm.com with regard to "Several Real World PM Issues" sighted by the member.

There is no single (definite) answer to questions posted by you. I'd rather term those as "Situational", i.e. given the scenario and importance of a given attribute (or set of attributes) you make a decision. Nonetheless, I have tried responding those based on my assessment.

Q1. Your application is in testing for the last 2 weeks and you are supposed to deliver the application at the EOD. Your testing team has found a major flaw in your application in the afternoon. You cannot miss the deadline and your developers cannot fix the bug in couple of hours. How do you handle this situation?

#1 - You have to have a communication with customer. Apprise him / her of the situation, and your alternatives, i.e. if non critical, making a delivery with known issue, and patch / subsequent delivery with definite date etc. One thing is sure, you cannot ignore the customer, and just sighting a problem is also not enough. You have to have options with clear execution plans and outcomes, before you decide to discuss with customer.

Q2.Your team is into the 6th Iteration of 8 Iteration project. It's been really hectic for the team for the last couple of months as this project is very important for your customer and to your company. You have started noticing that some of your key resources are getting burnt out. How do you motivate these resources?

#2 - You have identified the need for motivation; however, do you also know what would motivate them? If you have also uncovered the attributes for motivation, it would be a matter of analyzing and planning of resources, within given constraints to address those attributes. Otherwise, first understand the factors / attributes that would contribute to their motivation, and then address those. Another situation could be the "work" itself is de-motivating. Under these circumstances, you need to assess the "rotation" on one hand, and make them realize their contributions and your gratitude for what you all have collectively accomplished. Further, you also need to apprise them bigger accomplishment on completion, and the satisfaction (reward, if any) that you all would be getting.

Q3.Yours is a dedicated team for a customer and it's been a dull period for you and your team. You are not actively involved in any development activities. Your team is providing support to the application, which you have delivered earlier. Your team is getting bored as the application stabilized now. Due to budget issues, customer is not going to give you work for another 3 months. How do you motivate the resources?

#3 - Any development activity would come to end some day- a fact that cannot be ignored. However, the business needs a definite and continued stream of revenue, which can only come through long running (continued) work. Think of rotation, building something innovative / constructive in "excess capacity" times, conduct trainings, or simply make them realize the "Job Security" that they enjoy because of mentioned work. However, I personally believe that any motivation would exercise only be effective, if it is based on study of a person, environment, and constraints.

Q4. You have a resource that who is not happy with his job and complains all the time. You have noticed that because of that the team morale is getting spoiled. How do you handle that resource?

#4 - Educate the person of consequences. If problem still persist, fire the person. The reason being, probability of correcting a non-performer (work wise) is more (and the cost is less) as compare to probability of correcting a person (and the cost is more), who may be brilliant, but does not believe in his / her work or organization policies.

Q5. Conflict should be resolved by person involved and immediate manager. Is this CORRECT???

#5 - Depends on the situation, and maturity of the person(s) involved. I'd be happy to provide my response, if you can elaborate.

Q6. There was a situation where more than one-way to accomplish the same task. Your onsite tech lead and offshore tech lead has different opinions about doing this and the feelings were very strong. Both are very important to you. How do you react to this?

#6 - We all know that there is no one decision, which will make all happy. Therefore, the best approach would be to go by merits, i.e. ask them to demonstrate and debate the merits of each, and quantify the merits via PUGH metrics (you can also make use of QFD tool, though with restricted usage). This way other person would see the merits of decision, and would also encourage him / her to build alternatives and do their thorough evaluation in future, even before some alternative is proposed.

Q7. You are at the customer's place and your application is in UAT/stabilization phase. Your customer comes up with a change request and says that it's a minor one and he wants to see it in the next release. What will be your response/approach to your customer?

#7 - The facts of the life is you cannot withhold or say no to business need. The customer is proposing a change, because this is what is required for his / her business. Therefore, work towards adapting changes with minimal disruptions. Therefore, apprise them of your change management process, and if the impact (adverse) and subsequent cost is more than the ROI / gain, the chances are that customer will either put the change on hold (if non critical), or will approve the "change implementation", as submitted bu you. The fact is, you have to be flexible, and you need to make the customer realize that you are flexible; however, every change has associated costs (not necessarily in terms of $$).

Q8. Your team is in between iteration. Your customer wants few more items to be delivered in that iteration which you are working now. How do you react to your customer?

#8 - Refer response #7.

Q9. How to motivate team members who are burned out?

#9 - Refer to my earlier response under similar situation.

Q10. Your customer wants a bug to be delivered at EOD. You have got the BUG/CR information in the morning. It will not be possible to develop, completely regress this issue and deliver it at EOD. How do you approach this issue?

#10 - What is your SLA in this regard? If the demand is as per agreed SLA, you should have taken enough measures to address these situations (hopefully). If not, and if you are not a regular defaulter (on your SLA), customer would agree for exception (subject to conditions / situations). However, if you are a regular defaulter, you need to put together your acts to improve the situation of SLA front, as ultimately it would have an adverse impact on relationship.

Now, specifically for mentioned problem (if you really need to have answer for immediate problem alone). Find out the touch points, critical flows, and test as regress as per critical path. If you do not have capacity issue, and parallel activities are possible, think of doing things in parallel and then converging and following a sequence.

I'm not bringing in automation and other things, as I'm assuming those as given.

http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3027

Business Case Structure

The following text was my response to a post @ allpm.com with regard to requirements of a Business Case.

If you have a business case, this itself means that you have a reason to initiate a change in existing process / environment (could be a project / program or as simple as a single task) such that it would favor the business.

The structure of a business case depends on the need and the complexity of the case. It could be as simple as "logical reasoning", or could be a very elaborate one too, if you consider the "functional" plans within a business case.

To give you an example, you may consider making a case by detailing information under following heads,

1) Background - details of as-is" process, leading to inefficiencies / bottlenecks. Try to include current measures (performance / capability) too.

2) Details of Project - You need to define the objective / goal, benefits profile, stakeholders profile, and scope of your "case".

3) Cost Benefit Analysis (CBA) - Analyze for business / operational / financial impacts for all costs and benefits. Support it with ROI figures (NPV, IRR, Payback Period)

4) Environment Analysis - More to do with the environment under which an organization operates. By doing this you are assessing the tactical / strategic impact. However, you would definitely not require this for each and every business case, unless it impacts the organizational strategy.

5) Option(s) Analysis - Analyze the options that were available to you, and why you have chosen the suggested approach. My preferred choice in this case would be to make use of QFD (though PUGH matrix is designed for this).

6) Technical Analysis - If applicable

7) Risk Analysis - Remember identify, Analyze (Quantify / Prioritize), and suggest mitigation approach (if required). It would also feed into your CBA.

8. Project Schedule and Resources - Your commitments and organizational support that you would require to complete.

9) Measurements - To check on the progress, and alignment to set goals.

10) Summary

It goes without saying that all of these points you would summarize in one or two pages for top management / financer or for someone who just wants to have a gist of it, in form of executive summary.

Now, as you can see, you can make it as elaborate as you want (or required); however, one things is sure, whether a concise one or an elaborate one, on completion of this exercise you are aware of what, why, and how the problem(s) needs to be fixed (bare minimum).

If you want you can read through http://en.wikipedia.org/wiki/Business_case to check what has already been documented on this topic.

http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3089

Risk Management Approach

The following text was in fact a response to post @ allpm.com, wherein "risk" as opportunity identifier mechanism was discussed.

The article that you have been referring to primarily state that one should also look for opportunities. I personally believe that it all depends on person's mindset, and situation. Let me explain, what I mean by this.

The normal risk exercise is conducted with a mindset of "aversion", i.e. we want to avoid the risk. That is why, we do the exercise of identification, quantification, prioritization, and MMM. However, this is also true that this exercise is primarily carried out at a project level. As evident from the approach itself, the benefits arising out of this exercise are limited, as your gain is directly linked with the success of "aversion" of risk.

Now, let me broaden the scope; let us say you have to do the same exercise from a program / functional unit / organization perspective. It is obvious that in this case “aversion” exercise is not enough, and we need to broaden the scope to make an assessment from SWOT perspective. This is exactly where a relatively new approach fits in, i.e. "Strategic Risk Management" or "Enterprise Risk Management".

To be brief, this approach looks at strategy / functions / activities from a broader perspective, i.e. it would evaluate the strengths, weaknesses, opportunities, and threats. It would start from strategic analysis, and would encompass the working of an organization. It makes sense too, the reason being at this level "aversion" is not enough, as the environment is under change, and even to sustain at current level you would require more than aversion; for a simple reason, strategy cannot be independent of environment, and you work as per your strategy (hopefully).

Now, the question is, “Should we always go for the "wider" approach”? The answer is "NO". You have to assess the impact of work, cost associated with such study, and returns on proposed investment. If your project does not have any wide ranging impact (as true for many, if not most of the projects) on organizational functioning, the "aversion" exercise should suffice.

In essence, it requires a prudent decision to choose between the two. No approach is better than the other, it is the context, which makes one better than the other.

http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3043

Agile / Lean Vs. Structured Project Management Model

A lot has already been written, and even more may come out in future; however, to the astonishment of most of you I find that in no way a structured SDLC or Project Management is different from (or inferior to) Agile / Lean approaches.

Let me first present the case for Project Management. The CMMi or any other structured approach provides only guidelines and general framework for Project Management. At no point it suggests that it should has to be done in THIS was only. As you would agree with me the implementation happens as per "interpretation / understanding" of the person / organization. Since, it is a human tendency to adopt what is readily available, without giving much importance to adaptability to given environment or need, we end up having an incompatible implementation. Since, the implementation itself is faulty; you cannot expect it to bring correct results to you.

Take the case of CMMi / PMBOK the activities suggested under each are not replaceable or optional; one needs to carry those out, irrespective of approach chosen. However, the difference lies in implementation. For example, will anyone suggest that the any of the following items are optional (not a complete activity list);
1) Project Initiation
2) Project Planning
3) Project Execution
4) Project Monitoring and Control
5) Project closure

I do not think so. As I have suggested earlier the difference lies in its implementation and execution.

The promoters of Agile approach suggest that CMMi or any other structured approach is rigid and hence is not compatible with today’s changing environment. However, the fact is, the environment was never constant, then why is that we are realizing it only now?

In my view the Agile / lean approaches are nothing but the best practices of Project Management evolved over a period of time, and even these approaches are structured. Let me explain how.

The preachers and practitioners of Agile approach suggest that it scores over structured approach as with this approach,
1) One knows that “What needs to be carried out, and in what order”.
2) We need to involve customer; customer is the focal point.
3) We need to have “iterative” approach.
4) We should be ready to adopt the change.
5) Things are simplified.
6) Team takes the ownership, and there is no hierarchical, role based activities distribution
7) It promotes trust….. (and may be some more)

Now have a look at the above mentioned points, and assess what CMMI or any other structured approach has to say about these points. Let us take each point in detail.

One knows that “What needs to be carried out, and in what order”

What it essentially means is that we have a goal to achieve, and we never loose the sight of the goal. If goal were to change over a period of time, so would our activities, to align with the goal.

Now, in any structured approach you document the goal, get a buy-in of all stakeholders (a formal artifact is more from an evidence perspective alone), and work towards the goal. Again, if goal were to change, we re-establish the goal and align the activities towards achieving the revised goal. Where is the conflict in two approaches?

The conflict starts, if the goals were documented and then had been forgotten. Now, it is a problem of the person, and the enforcement, and not a problem of the methodology or process. It is a common sense that if we loose focus on goal, the end result would be far from defined goal.

Now, people may ask, why is that we do not loose a focus in “Agile” approach, though it is very common to loose a focus in structured approach. I would say that the answer lies in span / duration; invariably the agile approach is applied on “short” duration projects, hence, it is easy to retain the focus. Take it a little further, and apply on long running projects (with multiple teams and stakeholders), and you would find that you do not have an option but to document and monitor it on a regular basis. So, where is the conflict?

We need to involve customer; customer is the focal point

It is said the customer involvement is critical to the success of the project; invariably in all projects a client representative works with the team.

Well, I could not find any incidence either in CMMi or any other structured approach, where it had suggested that customer involvement in non-critical or we can do away with the customer. In fact, Six-Sigma projects are driven through “Voice of Customers (VOC)”, and even in CMMi model, customer is the focal point, as we always maps the success of the project to fulfillment of customer needs. In fact, it suggests to plan for stated as well as non-stated needs.

Again, I have failed to find any conflict. We need to communicate with client, take and provide feedback, incorporate feedback, involve him / her in verification / validation process, on a periodic and event driven basis. This is the premise behind any project executed within CMMi or any other structured approach.

How frequently and diligently / sincerely do we do that; it's a personnel trait, and no process or methodology can take it to the acceptable level of projections. The enforcement is the key. If your enforcement polices / points can ensure involvement, you would not face any problem on this front; independent of methodology / practice used.

We need to have “iterative” approach

Again, I have not come across incidence where CMMi or any other model, where they have advocated a “Waterfall” model for all projects. Whether you need to adopt a “Waterfall”, or any “Iterative” (“Incremental”, “Spiral”) model, it all depends on clarity on requirements, project size and customer needs.

If the requirements are straight forward, project is of short duration, say two / four weeks, with as much effort; in this case even “iterative” approach would be a burden. Therefore, it would be naive to say that “Iterative” approach is the only approach for success. However, it may so happen that you (or your organization) had been managing only large projects, therefore, “iterative” approach seems more appropriate.

The choice for approach is “need” dependent, and has nothing to do with adopted model, i.e. structured or Agile.

We should be ready to adopt the change

It is true that we should be ready for change; however, it does not mean that those can be “taken-in” haphazardly. I’m sure even in “Agile” approach one would assess the impact of change from solution, dependency, cost, and time perspective. That is, whether it is feasible (the change / requirement), what is the impact on overall solution, where are the touch points, how much will it cost, and whether it can be adopted within given timeframe or would require more time.

What CMMi or any other structured approach suggests that we have to have a clearly defined change management process, which helps in easy monitoring and tracking of change. It may have mandate for approvals; however, that is there in “Agile” model too.

Now, people may suggest that in Agile the change is assessed and approved by team, and it is less time consuming. However, again, what prevents you implementing this in CMMi or any other structured model?

If the project size is small, and impact is also small, let the team (or any other representative) take a decision, and carry on with the task. However, again be it “Agile” or any other model, you cannot violate the basic rules of change and configuration management.

A well defined process is to ensure that changes are easy to take in, and implement. The “rigidity” is an external factor introduced by human psychology; it has no bearing with process or model. The rigidity comes from “fear of failure”; failure on any front, i.e. missing out on solution fitment, effort, time, cost, quality, productivity or anything else. If one is “insured” from these failures, all “changes” could be embraced willingly.

Therefore, we need to ensure that we address the “fear of failure”, we would find that even CMMi or any other structured model are as adaptive as any agile model can be.

Things are simplified

Things are simplified in Agile as compare to structured approach. I believe it is more because of “size” than any model enforced process.

No model suggests that you need to incorporate complex design, complex solutions, create a cobweb so that decisions get entangled under those cobwebs.

The processes are defined to make life simple; because, process is nothing but a set of sequence of steps, with identified inputs and expected output(s) / outcome(s). The problem starts when people equate process with “excessive” documentation. Please mind the world “excessive”. That is, we are aware of the fact that even “Agile” model cannot do away with the “documentation”; instead, it propagates “appropriate” documentation.

The reason being in the event of no documentation everything becomes person dependent, and trust based. However, the problem is no system in the world can operate (successfully and repeatedly) and grow, with having people dependency.

That is why the processes are defined and documented so that person dependence can be reduced (if not removed) to an extent where the replacement is “feasible” and relatively less painful.

Team takes the ownership, and there is no hierarchical, role based activities distribution

Again it boils down to “size” of the project, and interpretation and implementation; independent of model.

It is evident that if the project size is small, it makes sense to have a flat hierarchy, as activities can be overlapping and can also be shared, without impacting anything else. On the other hand, if the project size is big, the flat hierarchy would bring in chaos; and no one would be clear on “accountability”. Therefore, one needs to bring in “Operational” hierarchy, so that operations can be segregated (from accountability perspective); however, still no one prevents or directs / dictates that discussions and decisions can’t be collective.

The operational hierarchy is to facilitate the “production”; it is the “implementation” and “ego”, which deviates it from the “original” implementation. Therefore, if you introduce these two variants in “flat hierarchy” of Agile model, even in small projects, you would feel the pain of wrong, delayed, and bureaucratic decisions.

It promotes trust

I personally believe a trust can be formed over a period of time, if and only if people perceive that ones words match his / her action. This gets propagated if you work together, and if there are interdependencies.

The Agile model brings / necessitates closer association and working; as the model cannot work without it. But, the structured model is not opposed to it either. Whether you put two people or single person on a given task is your decision; model has nothing to do with it.

In fact with well defined processes, well laid out role descriptions, it should foster trust, as those should ideally be helping in more predictive outputs / outcomes.

To summarize, agile or so call structured approaches, there is no difference at “core”. The agile propagates the “best practices” of project management, which if implemented in structured approach would yield the same result. The reason being, at the end of the day even agile model follows some structure; as without pre-defined structure it becomes people dependent, and one cannot have any degree of prediction under those circumstances.

This has also been published by me at http://allpm.com/index.php?name=PNphpBB2&file=viewtopic&t=3011