SCRUM Portfolio Strategy Part 1

With increasing demand of sophisticated IT Products and and services every organization is thriving to meet the demands with its limited supplying potential. The invariance in supply and demand of IT Solutions forces organization manage products through a streamlined process known as Portfolio Planning. All organizations need to make economically sound decisions to manage their product portfolios. But to my surprise not many organizations have a well defined portfolio planning strategy, and even if they have they are fundamentally not aligned to the core AGILE principles. In this current topic I will throw light on some important portfolio planning strategies which can be applied to connect to a AGILE compliant portfolio planning process.

First lets try to understand what a portfolio is. Portfolio is simply a backlog of prioritized products. Portfolio can contain any on going products or newly envisioned products. The key output of a portfolio planning process is to select and prioritize the most value driven products.

Portfolio planning is a never ending process. We are responsible to manage a portfolio as long as we have products to implement and maintain. You might wonder who is responsible for planning portfolios?  Well in my opinion portfolio planning involves a set of key participants like Internal Stakeholders, Product Owners and Technical Experts. Internal Stakeholders are mostly business driven people who measure the value and economics of the products under the portfolio. Product owners being champions of their products play a key role in the portfolio planning process. Product Owners act as advocates of their products. Technical experts do participate in portfolio planning to ensure all organizational technical constraints are well factored in a portfolio planning process.

As I mentioned earlier Portfolio Planning is done for both active products and newly envisioned products. The inputs for active products in a portfolio plan comes from factors like customer feedback, updated cost, technical debts, scope, product road map, market research data which help in deciding the future of currently active products.
In case of newly envisioned products its usually the business case which feeds as an input for portfolio planning and to decide the future of the envisioned product. Factors like Cost benefit analysis, sales forecasts and budgeted financial statements influence the portfolio planning process.

The prime output of a portfolio planning process is the prioritized portfolio backlog, every portfolio planning process is driven through set of phases and strategies to achieve this prime output.

Agile Portfolio Planning Process Model:

Above figure illustrates the AGILE portfolio planning model which consists of 4 underlying activities:

1. Scheduling 
2. Managing Inflows
3. Managing Outflows
4. Managing In-Process

The above mentioned Portfolio planning activities are made up by 11 AGILE strategies as shown in the figure above. I will briefly introduce you to most of these strategies and how they are implemented to produce a well thought and economically fruitful portfolio backlog.

Scheduling
The three key scheduling strategies used in portfolio planning process are:

1. Optimize Life cycle profits: Reinertsen recommends using economic measurements like Life cycle profits to sequence the portfolio backlogs. Basically it involved understanding of which products aim to higher profits during its entire life cycle. Products are ordered and sequenced in the product backlog as per their life cycle profitability. 
2. Calculate cost of delay: Next strategic measurements comes with cost of delay. This accounts for the cost incurred in not considering the product as part of the portfolio. If two or  more products have same cost of delay measurement then the one with the shorter implementation cycle is chosen first. Calculation of Cost of delay is in itself a very complex strategic input which I will discuss in my next blog post.
3. Estimate for accuracy: To precisely schedule portfolio backlog items it becomes very important to consider the impact of cost of the product as this affects the overall life cycle profits of the product. Agile SCRUM believes in relative sizing of portfolio items and most of the organizations use techniques like T Shirt sizing( S,M,L,XL,XXL) to size their portfolio items. Relative sizing strategy helps in quickly and accurately sizing portfolio items and thereby eliminating wastes like coming to precised estimates which is not so helpful at the portfolio level. This also helps in making quick go/no go decisions for marketing teams. Example of T Shirt sizing : Extra-small (XS) $10K to $25K
   Small (S) $25K to $50K
   Medium (M) $50K to $125K
   Large (L) $125K to $350K
   Extra-large (XL) >$350K

Managing Inflows
Inflow strategies help in determining the rate at which products can be inserted into the product backlog and the rate at which they can be pulled out. They also help in product funding decisions by considering the economic aspects of the products.
The key inflow strategies can be summarized as follows:

1. Economic Filter
2. Arrival/Departure Rates
3. Embrace Opportunities
4. Plan shorter and frequent release cycles           

In  part 2 I will elaborate Inflows/Outflows and In process strategies and how they contribute in coming up with a well balanced enterprise portfolio.
Stay tuned !!!  

Real curse in Agile implementations - The Technical Debt

Like the great economists have mentioned "with every activity there comes a debt", same applies to IT projects and projects in other disciplines as well. With every project activity a certian kind of debt is always associated.

I personally compare technical debt analogous to the interest payment over a borrowed or spent capital. Its a debt realized due to poor project and engineering practices which sometimes can accumulate and turn out to be very hazardous for the project. It might also lead to project bankruptcy.
In this article I will try to explain you the kinds of technical debt, what causes a technical debt and steps required to minimize or resolve these kind of debts in your projects.

Technical debt can be classified into following categories:

• Naive or Reckless debt
• Unavoidable debt
• Strategic debt

Naive or reckless debt occur due to sheer negligence or lack of understanding of project domain and its practices. Few basic examples of a reckless debt can be, poor design, lack of platform and domain knowledge, too many defects, more manual over automation tasks, poor integration of architectural building blocks, poor coding practices and insufficient test coverage. Such debts can be reduced by undergoing proper trainings and improving practices across the team. Scrum framework due to its short iterative and incremental approach provides opportunities to inspect and adapt such kind of debt very early in the projects thereby reducing the probability of such debt to increase as the project progresses.

Another kind of debt in known as Unavoidable debt, for example if a project being built uses a third party building block or component and later on if the vendor releases an update for the component which disrupts the usual flow of the project, such situations are very common and these kind of technical debt are unavoidable and can be foreseen upfront.

The third kind of debt is the Strategic debt, such kind of debts are usually time sensitive. For example a capital constrained organization might ask the project team to cut project and engineering practices to achieve timely go to market or if the project is running out of capital then it might downgrade the project to meet cost constraints. More specific example would be, suppose a project is running out of money and the organization decides to skip performance and load testing for a piece of software to save time and money. This might benefit the project short term but it comes with its own consequences later in the operations cycle of the project.

Consequence of a Technical Debt:
Technical debt comes with serious consequences impacting all aspects of the project from its performance to customer satisfaction and project economics. Some common consequences can be summarized like:

• Increased time to delivery
• Significant known defects
• Rising development and support costs
• Decreased predictability
• Under performance
• Atrophy
• Frustration and decreased customer satisfaction

Specially in SCRUM implementations if the technical debt grows beyond control then the velocity of the team reduces so time to market increases. Increase in defects also interrupts the usual flow of values added development and hence increases Work in progress items leading to added costs in terms of time and money. Due to the unpredictable tipping point  technical debts might soon pile on if ignored during project development phase and its consequences might reflect in the support and operations phase which leads to extra cost of removing the defects identified late in the application life cycle.

Atrophy is another very common consequence of high technical debt. If the product is delivered to the customer with high technical debt then it might loose its significance due to overspending and defects. This might force the customer to look out for new products or substitutes as soon as an opportunity hits them.

Now I would like to share you some common observed reasons that account to high technical debt in projects. Most common and frequently observed reason for different kinds of debt is the pressure to meet deadlines. Its very usual that during Agile projects the teams velocity might not remain consistent across sprint cycles. Their velocity might decrease due to unavoidable reasons and with decrease in velocity comes the fear of not meeting the deadlines. During such situations teams usually try to falsely accelerate the velocity to meet deadlines by cutting down the scope or engineering practices. For example if a team skips regression testing or performance quality compliance checks then such reductions are accounted as technical debt which might come to attention late in the life cycle.

I wonder few project teams intentionally cut down testing activities of their products to increase velocity but eventually land into a more compromising situation due to high technical debt. SCRUM encourages Test and behavior driven development TDD/BDD, which makes the development and testing to run parallel before the deliverable meets its definition of done. A strong definition of done reduces the technical debt rising due to engineering practices and recklessness.

Every project team should proactively manage technical debt in their projects. Any kind of technical debt can be managed by following these processes right from the beginning of the implementation phase.

• Managing the accruals of the debt
• Making the debt visible 
• Repaying the debt

Apart from following good engineering practices and processes its very important for all SCRUM team members to understand the economics behind technical debt. Lets consider a case study here to better understand the economics of the debt.

Assume
1) Cost of development per month = 100K $ for a ten month project cycle
2) Project is running behind schedule and budget
3) No option for any scope cut as all features are minimum marketable requirements (MMR)

Now  if the project was to be delivered on time then the actual cost of the project would come out to be 100k$ x 10  = 1 million dollar
But due to delays in the project the expected time for completion is say 13 moths. So the expected project cost turns out to be 13 * 10k$ = 1.3 million dollar.

Under this situation the management feel that a three month delay would lead to 300K $ loss in sales and decides not to overshoot the budget by another 0.3 million so they ask the team to cut the practices and testing to meet 10 month deadline.  So in order to save 300K $ and 0.3 million they increase the technical debt.

Now suppose after three months of the release the technical debt incurred starts causing disruptions in the operations of the product and now the management decides to repay the technical debt and asks the team to estimate for the removal of potential disruptions in the product. Team estimates around 500K $ for removing the disruptions. Now if the management executes this repair cycle the total project cost might go above  1.5 million $ +  Interest value + Other factors which might be way above if the technical debt was taken care right before release which could come out to be 1.3 million $ + 300K $ (Cost of sales).

So under economic analysis scenarios it becomes very important for teams to properly identify the cost and time value of the technical debt and decide on accepting the debt early or ignoring it for future. It becomes the core responsibility of the Product Owner and the Development team to account for technical debt at the right time with high priority to avoid an extra interest payment later.

Demystifying IT Budegting

Few years ago I was asked to budget a new Software Project for a digital records system for a private organization along with several project managers and PMO analyst. To my surprise, I heard people saying they do not understand the accountability of IT expenditures. It is very common across small and big project teams, people misunderstanding the IT expenditures accounts and finally landing up in creating purchase orders which turn up an asset into a capital expenditure.

Most of the organizations do have in house IT Finance controllers who act as guardians to Project and Portfolio managers but sadly not all of them understand the basic CAPEX and OPEX accountability. IT managers might not understand the accounting disciplines and accounting folks might not know the underlying activities which derive IT expenses. IT managers usually give vague numbers based on face value to accounting folks which are then passed on to BUs and Stakeholders, eventually the BUs fail to account for what they are being invoiced.

IT expenditures are always driven through a demand and supply pipeline which is governed by the IT investment portfolios. An IT investment portfolio usually contains a mix of strategies required for decision making and funding.

Key areas of IT investment portfolio include:

·         Keeping the light on: 70-80% of the IT budget is allocated in this area to support operations of existing IT applications

·         Generating revenue: 10% of the annual budget goes in to generating revenue through IT enabled services

·         Regulatory compliance: 5% of the revenue might land up in meeting regulatory compliance criteria

·         Strategic Initiatives: Another 5% of the share might go into new initiatives for organizational excellence

Based on the above portfolio mix Projects and applications are proposed and funded maintaining the balance across all areas.

IT projects usually go through a strategic pipeline before they can be initiated and realised. Every IT project goes through following high level pipeline phases:

Idea -> Project Request -> Project Planning

An idea is realized like a new opportunity evaluation or by capturing new demand areas within the organization. A project request ends up in preparing a thorough business case for seeking executive or portfolio board's approval which might also involve cost benefit analysis and sale forecasting. Finally the project enters into planning phase where projects are budgeted and estimated with high level planning. It is in the Project planning phase when project managers are usually victimized for misleading and inaccurate budgets and estimates.

In theory the IT budgeting process can be executed in two strategic ways

·         Baseline budgeting

·         Zero-based budgeting

Baseline budgeting is a process of analysing previous year budgets and deriving current year budgets by adjusting actuals, inflation and forecasting activities and events for coming year. This process is usually fast enough but lacks encouragement to people for questioning the previous assumptions and outcomes. This leads to fairly low budgets without the idea of bringing new activities.

Zero-based budgets always start from scratch. There are no previous assumptions or cost drivers for upcoming budgets. This aids in detailed analysis of new activities and events with fair justification of all costs. The downside being it's fairly complex and time consuming activity. Also with the lack of IT accountability knowledge Zero-based budgets might introduce new complexities in the accounting systems.

I would now like to throw some light on the basic IT cost categories and budgeting rules. All IT projects are either delivered by in-house IT teams or ESPs (External service providers). They are then shelved on IT infrastructures either completely owned by the organization or virtually owned through PAAS, IAAS and SAAS cloud services. These IT projects are further supported by the IT operations team and operations activity continues till the lifetime of the application which might range from 5-10 years. Few organization also scale up their IT operations to IT services which then define service level agreements (SLAs) with a clear description of cost and delivery criteria.

During the entire cycle explained above all projects, applications and operations fall under following cost categories which eventually provides an input to IT budgeting:

·         Hardware

·         Software

·         People

·         External/Vendor Services

·         T&E (Travel and Entertainment)

·         IT Overheads

IT overheads usually include facilities, training, recruiting etc. Summing up all of these costs leads to the final IT budget cost for projects, services, and applications.

Now the question here is which part of the above mentioned cost categories should be capitalized and which of them should go into expenses?

The international regulations and accounting standards provide three main budgeting rules for IT budgets.

·         Preliminary project stage or evaluation phase, which establishes the technical feasibility of the project. This is charged to OPEX, because if the project ended here, there would be no asset to speak of.

·         Software development or application configuration phase. This is CAPEX, because the end result is an asset, comprising software (bought or built), hardware and infrastructure.

·         Post implementation or production phase. This is OPEX, because these are day-to-day running costs. Note that software license maintenance is OPEX, whereas the licenses themselves (previous point) are CAPEX.

The biggest mistake most project and portfolio managers do is to assume IT as a pure service or engineering discipline which I personally wonder shouldn't be the case. IT projects and portfolios are strategic and logical apart from being service and engineering driven

Few basic budgeting rules can be logically understood and applied across individual areas of the various architectural building blocks and ceremonies, for example:

·         Functional design - OPEX

·         Technical design - CAPEX

·         Platform and Application Upgrades and enhancements come uinder CAPEX

·         Maintenance and small changes are usually under OPEX

·         One-Time activities like Data Migration or Profile migrations are usually OPEX as they don't result in long term assets

·         T&E usually come under CAPEX but some of it might go into OPEX depending on the project/application phase

Above mentioned rules can further be tailored while implementing IT budgets so that all derived budgets adhere to IT accounting compliance and are easily auditable. Though the above budgeting rules might vary across geographies and organizations accounting rules, for example at some places and IT hardware procurement less than $5000 is considered as an OPEX wherein costlier procurements are considered as CAPEX