Book Review – REWORK

Book Review

I have often felt guilty that I do not read books as often as I used to read a few years back. I now have a excuses from being time constrained to being overwhelmed by the information overload. One of the things that I had for 2019 was to pick up at least one book a month and read it. Rework was on my to-be-read list for a while now. What intrigued me most about the book was the reviews, people either just adored the book or rejected it outright. There were very few moderates.

The book is by Jason Fried and David Heinemeier Hansson, the guys who started basecamp and invented the popular programming framework Ruby on Rails. The book is not their story but what they learned in the process.

You might be tricked into assuming the book is for startups or entrepreneurs only. Well, it’s NOT. Of course there are sections in the book that deals with specific situations that entrepreneurs and startups face like funding, hiring and PR.But it is for anyone who is looking to cutting the rework and start working on things that matter,projects that make a difference or setting up business that add value and generate wealth. Its not a guide on how to quit your job.

The book talks about being lean and not to measure the success by size and bulk. The authors advocate lean organizations and teams that are easier to pivot to change. This is also evident from the size of the book which is quite lean – under 250 pages of actual content. At best the book can be described as a series of excellent blog posts that are stitched nicely together, but that’s what makes it an excellent read.

Book Review

Overall, the book wins with me. However if I were to pick my 5 favorite –

  1. Learning from your successes – Learning from your mistakes has been overrated. What you learn from your mistakes is what NOT to do.(which sometimes can be valuable). You actually learn from your successes. Some may find this arrogant, but it’s not that you will never make mistakes. You will make mistakes, but don’t over obsess over them. Move on. learn more about learning from success at https://www.businessinsider.com/we-learn-more-from-success-than-failure-2014-6
  2. Inspiration is perishable – Your inspiration does not last forever, what inspires you today may not ignite passion the same way tomorrow. Don’t shelf your inspiration, act now.
  3. Scratch your own itch – Looking for that business or great product idea? Find solutions to problems that impact you. The authors did that exactly and created basecamp to solve their project management problem
  4. Edit Ruthlessly – Its not the number of pages or the word count that make the difference, neither does it help to have a large number of service offerings if you can do justice. Be a curator or master chef. The first thing these guys do is edit and they do it ruthlessly devoid of any emotions. They trim the menu to carry only the specialties.
  5. The By-Product – The by-product if often left unrealised and ignored. The book rework itself is a by product of running creating and running 37signals.

Above all the thing that I really liked about the book was its quite different from your standard business and marketing books that I despise to the core. It’s one of those books i’d probably keep on book shelf to re-read often.Books teach us how to recover from disaster, click here to learn more.

As Seth Godin puts it very aptly in his single line review – “Ignore the book at your own peril”

PS – I have edited this review ruthlessly to keep it under 600 words

Around the CHAOS outlook – How 2011 played out and what to watch in 2020

How 2011 played out and what to watch in 2020

As the year 2011 wraps-up, I wanted to take this opportunity to share the top 10 (and interesting) technology and management trends and areas that dominated the scene in 2011. I also touched upon briefly what you can expect to watch within these spaces  the next year, 2020. The most significant technology space to watch out for me personally in 2020 would be the Green Technology space, However I did not specifically include it in the below list. Why? I believe each of the trends listed below will be influced on how Green technology evolves in 2020. Just a mention on this list would not do justice and pehpahs I would rather save this for a different post.

While this list is mainly based on my personal experiences and interests in 2011,  it is also inspired by social network interactions.

1. Agile Management makes further inroads– Agile management continued to make inroads and gain acceptance in 2011. Organizations recognized and realized its benefits. They even adopted various hybrid versions of agile even if they did not go completely agile. They tweaked agile to make it work for their custom needs like reporting, tracking and planning. We also saw PMI finally starting their Agile Project management certification program, learn more about it by clicking here

Watch this space in 2020 (for) – While PMI will continue to be one of the most accepted organization certifying and training agile management. There will be other leaders as well. Scrum Alliance for one, which is currently the leader in Scrum training and certification. Agile adoption might also see wider adoption extending beyond the traditional software development space, though i feel it will be still very much be within the IT industry (mostly).

2. Disaster, Risk and Security Management – While these have always been key areas of management, they become more valuable when managing in uncertain times and 2011 was no exception.Industry specific surveys have highlighted the importance of organization managed both risk and security.

How 2011 played out and what to watch in 2020

Watch this space in 2020 (for) – With computing over the cloud being the frst choice with organization, security, risk and disaster management will possibly be one of the keystones that holds the enterprise’s cloud architecture together.

3. Cloudy with AWS – If  you have to name one company that has propelled cloud adoption it has to to Amazon’s Web Services. The company continued to mature its cloud offerings both directly by extending its platform services across availability regions as well as adding innovative features like supporting multiple network interfaces with Amazon’s Virtual Private Cloud.

Watch this space in 2020 (for) – There is little doubt that amazon will continue to be a leader within the enterprise cloud providers, it will be an interesting space to watch out how challengers like Rackspace for instance will play. Of course Google has been eying this space and will look for consolidation with its cloud offerings for the enterprise.

4. SME Focused Management – This has been the subject of a never-ending debate, project managers or managers in general required to be a subject matter expert. A significant majority of ‘successful’ initiatives I came across in 2011 were led by managers with significant subject matter expertise. Needless to say the demand for these managers was also significantly higher.

Watch this space in 2020 (for) – While there isn’t much to watch out in this space in 2012 or in the near future except for the fact that the debate will continue to rage on. I for one believe that with uncertain times and agile management the talk of the day , the demand managers with the subject matter expertise will outpace supply.

5. Social Media & Google Plus – 2011 was also the year when you could not possibly ignore Social media. Time magazine has the person of the year as “The Protester” , aided with social media. Social media moved beyond sharing updates and pictures to  shaping both geographies as well as brands. Google stormed back into the social media scene with Google+ and they did their homework this time around. With around 70 million active users in 6 months, it looks like they have finally managed to get social media right this time.

Watch this space in 2020 (for)  –  I hate to put my foot in my mouth but 2020 might be just as well the year of Google+. There is also the much anticipated IPO from Facebook. An interesting trend here would also be the segmentation within the social media space with niche palyers like Instagram, Path & Pintrest all fighting it out for spotlight.

6. Managing Big Data – The systems and technology to manage Big Data finally seemed to have arrived in 2011. Thanks to cloud computing, both platform based like Amazon – AWS and service based like cloudera, the technology to exploit these huge datasets are now available beyond large organizations that could afford to deploy multiple clusters of hardware.

Watch this space in 2020 (for) – With the systems and technology evolved, what would be interesting to watch is how organizations ultimately use this data. A small number of organizations have already started doing this, but 2020 will definitely be the year when organizations finally start to exploit these datasets to provide better products and services.

7. Email’s waning its majority – One of my personal favourites,  in 2011 though email continued to be the primary channel for communication for the enterprise, its dominance seemed to be threatened if not completely shaken. Collaboration tools, instant messaging and social media services all played their part in taming the email beast. 2011 is also the year when a large listed technology company went cold turkey and completely banned internal email.

Watch this space in 2020 (for) – While I am pretty certain that 2012 will be no different than 2011 for email with respect to its waning majority, what will be interesting to watch is the organizations that will adopt alternatives and those alternatives themselves.learn more about disaster recovery at http://www.aroundthechaos.com/agile-disaster-recovery-strategy-using-the-cloud/

8. The Statups and IPOs – 2011 was the year for startups and IPOs. There were some really innovative startups like Instagram ,Quora, Launchrock and Stocktwits to name a few. Unfortunately 2011 was also the year for ridiculous IPO offerings, with Groupon leading the pack. While most have them have been subject to market correction since then, there are still some overvalued items out there.

Watch this space in 2020 (for) – Facebook of course will come up with possibly the biggest tech IPO. There are also list of startups that will try to ride on the IPO wave along with Facebook. With a little inspiration, luck and caution you actually might profit from this trend. Despite uncertain times, watch out for the innovate startups that will continue to get the much needed funding and possibly change the way we work and play.

9. Enterprise Project Program Portfolio Management Systems – The EP3M space seemed less crowded this year, however there are still no clear leaders. While Microsoft and Oracle dominate this space with MS Project Suite and Primavera respectively, they are yet to be established are clear leaders within the quadrant . There were some clear challengers this year specially the companies with on-demand, SAAS and cloud based offerings which both the front runners seemed to lack, at least in 2011.

Watch this space in 2012 (for) – This will probably be an interesting space to watch in 2012 as well. Will the dominant players go in for a on-demand agile model or will one of the challengers finally scale-up at an Enterprise level to threaten the front runners.

10. Apple & Steve Jobs – I had to include this one, no matter how much you love to hate apple, they do come up with the most innovative and stable products. This was obviously a mixed year for the tech giant. While the world will continue to miss Steve for his innovation and vision, Apple did prove (once again) that the iPhone continues to be the most popular smart-phone till date.

Watch this space in 2020 (for) – The television revolution. As apple plans to revolutionize televisions like they way it revolutionized the cellphones and music, this space and Apple in particular will be an interesting space to watch in 2020.

So did I get it close for 2011? What do you think will be the most interesting space to watch out for in 2020. Something that I missed?

Agile Disaster Recovery Strategy Using The Cloud

Agile Disaster Recovery Strategy Using The Cloud
Traditionally disaster recovery (DR) solutions have been both expensive and often time consuming to roll-out.The solution often tends to carry around mass which makes it difficult and costly to both to implement initially and to adapt to rapidly technology or economic environments.

 

An agile DR solution that is built around the cloud aims to address these very problems by focusing on being lean and flexible

The Agile (Lean) approach

The most important part of any DR solution is to achieve business continuity in case of disaster resulting in a system downtime and reduce any recovery times. This involves securing your business critical data and ensuring its availability as well as restoring critical business and operational processes. As such instead of going in for a big bang approach for a DR solution where you aim for a 100% fail over it might make business sense to approach this in an agile and iterative manner.learn more about project scheduling at http://www.aroundthechaos.com/5-steps-to-get-your-project-schedule-correct/

Let’s break this down

  • Business Critical Data – The core concept behind any DR solution is sustainability in case of a disaster and fall back on the primary site as soon as possible, with that in mind do you really want to include your complete data set as part of the DR solution? Probably not.Have a strategy for your different data sets including your master data, your transactional data and your archived data. Depending on the complexity and the IT Structure this data might be distributed or reside with the same database.The idea here is to identify your business critical data that will enable your business to operate. This needs to part of your DR strategy first.
  • A Product Backlog of Your Business & Operational Process – As with data, it is equally important to identify the critical business and operational processes that your enterprise will need to be able to operate. This will need to go hand in hand while you identify your critical data sets and system. The systems and data sets that will eventually be part of your DR solution scope will be the ones that are needed to support these critical processes. Think of these process or capabilities as your product backlog. What is critical gets higher priority than others, for instance while your order processing system will be need to part of your DR solution do you really need the systems to support internal procurement process? well, you may or may not depending on your business.
  • Break it Down – Technically, smaller wins will increase your probability of success as compared to the big bang approach. For instance if you are aiming for a full fledged DR capability at a remote site in a different geography, you may want to start first by just implementing a remote backup solution and then build upon that to go in for a complete standby. Be cautious here, you do not want to overdo this and decompose your goals too much or too often. I am not a big fan of thumb rules, but I will do an exception here. Break it down to a delivery item that adds value.
  • Test Often but Test Agile – Test and validate your DR procedures regularly. You do want to wait till an actual disaster happens to test the effectiveness of your DR solution. At the same time it important that you have a iterative plan that has a DR validation built in periodically. Dont disrupt your existing business process or system to validate or test DR.learn more about Agile by clicking here

Agile Disaster Recovery Strategy Using The Cloud

Leveraging The Cloud

Building your DR solution over the cloud can help cut the mass and add agility for around the DR solution. It also gives you the flexibility around the actual solution itself, for instance you may opt for a active(warm), always-on DR solution or may go in just for an on-demand passive solution.

Critical factors that influence a lean DR solution built around the cloud could include

  • The Time Factor – The essence of having an agile approach to DR is the ability to roll-out the DR solution quickly. You don’t need to invest time and money to setup the upfront massive infrastructure to get going. Starting off using a PaaS or a SaaS model which would host and manage your DR site and solution might work just as well.
  • The Cost Factor – One immediate advantage of implementing a DR solution over the cloud is the cost. A DR solution over the cloud which leverages an on-demand model would be more cost effective to roll-out as opposed  to a traditional in house or a even a hosted solution. It is not just the reduction in costs that is a factor here, but also value add that a cloud based business resilience solution brings in by leveraging technologies like server virtualization and rapid data replication to reduce recovery times.
  • The Change Factor – DR solutions build on and leveraging the cloud have the ability to pivot quickly.These solutions can be scaled up or down rapidly in response to changing business dimensions. Also since there is seldom any upfront investment on technology, the dependency on the same is also significantly reduced.This allows the solution to be both lean and flexible.
  • Solution Robustness – You can quickly and cost effectively build a DR solution that involves Multiple DR Sites via the cloud. With on-demand instance provisioning you can add robustness to your DR solution by having your instances spread across geographic regions. Under a traditional DR solution this was part of the trade-off that organizations had to make due to the cost and time involved.
  • A Managed Service Model – Sometimes it might make sense to have a managed model for your DR solution.Under a could based managed model, you let the provider manage the complete disaster recover solution for you, including the initial setup and the ongoing validation of your DR process.

As always we are all ears on listening to your experiences on implementing DR solutions over the cloud. Jump in.

5 Steps to get your Project Schedule Correct

Project Schedule

The following was originally a guest post for the steppingintopm blog

When I was asked to come up with a guest post for Stepping Into Project Management (SIPM), I wanted to come up with something that was close with the central theme of the blog, which is helping Project managers on starting their journey on the project management space. As a newbie project manager (or for that matter even as someone who has been managing projects for sometime) getting your project schedule correct early on is critical as this will be one of the important baselines against which you would track your project execution.

Project Management is especially very good for big projects, project management is used in many industries like web designing, text tile industry indeed project management is required in every sphere of business, web designing field is fully dependent on project management as in this field success of project depends on good project management as there are deadlines and you have to meet deadlines, learn more about Web Designing at https://cliquedmedia.com/web-design-ireland/

I also want to call out one common myth / misconception here – A Project Plan is different from a Project Schedule – no matter what they tell you. I will not go into details on this post, but to summarize – A plan will include your strategy on how you will get there i.e. the end goal (scope) whereas a project schedule is as the name suggests a schedule of tasks along with their respective

Project Schedule

So it is critical that you get this correct as you take your first steps into project management. Here are five simple but important steps that will help get your schedule correct

  1. Start with the WBS – First things first. Start with decomposing your scope into a work break break down structure. While there are multiple rules around this, the general thumb rule is break down your scope to work packages where each package can contain around 5-10 individual tasks. Again this is a just a rule of thumb, the level of the WBS would largely depend on your individual program or project. The idea here is to be able to tie back the individuals tasks that will make up your schedule to the capabilities listed in the project scope.
    Hint – Do not over do this to a level where you end up adding more complexity and management overhead.
  2. Get your estimates on track – The next logical step is to estimate the individual tasks that make up your work packages. How many resources you will need and how much time it will take take for these resources to get the task completed. Avoid doing any fast tracking or crashing at this stage. This is based on the assumption that you will be doing a bottom up estimation, that is starting from the individual tasks and rolling up at the work-package level.
    Hint – Make sure your estimation process & model is communicated and transparent to the project stakeholders.
  3. Analyze your dependencies – Most certainly your individual task will not be executed in silos. They will have dependencies. These dependencies and constraints can be in different forms. Example a task may have a dependency on a particular task getting started or completed as well as there may be tasks that are constrained to start or end on a particular date.learn more about project scheduling by clicking here.
    Hint – Don’t attempt to do this alone, get your SMEs involved in this exercise.
  4. Calculate your critical path – Once your have your tasks,estimates and the dependencies in place. You are now ready to to get the critical path. You either do this manually or through an EPM software that you are using. It does not really matter. It is also likely that you may end up with more than one critical path. You will need to pay attention to all the critical paths identified. It is also important to note that during the course of the project your critical path might change so your schedule is more of a living document and not static.
    Hint – Often there may be tasks outside your critical path that will influence your project outcome.
  5. Communicate – Now that you have done all the good work and have the project schedule in place, publish it. Your project stakeholders including your team need to be aware of the project schedule. The schedule would help little just sitting out there on your hard drive. again a reminder that your schedule is a live document and gets revisited during the course of your execution for instance every time you do risk assessment or change management
    Hint – Include a link to your schedule in your project status communications.

So that’s it, you now have a schedule baseline against which you can monitor and control your project.

Managing The Technical Debt Risk

Managing The Technical Debt Risk

The technical debt metaphor was first coined by Ward Cunningham in 1992 while drawing a comparison between the technical complexity of IT projects and debt in general. There are multiple definitions that exist and if I had to put in my own, here’s how I would lay it down.

“When technical work is delayed knowingly or unknowingly either to meet specific deadlines or  to save time and/ or effort which must be eventually done a technical debt is incurred.”

Like debt in general, where it is incurred to meet valid business objectives. There may also be valid cases where this technical debt is incurred for perfectly valid business reasons.Regardless of the reason, debt eventually needs to be paid off and a technical debt is not an exception as well.

However, unlike the financial debt, the technical debt is almost impossible to measure accurately.You do not have specific interest rates or payment schedules but nevertheless it is like any other debt and needs to be paid off (except in a few rare cases which we will touch upon later)learn how to cope with financial debt at https://www.consumer.ftc.gov/articles/0150-coping-debt

So How Does a Project Incur Technical Debt?

There may be a variety of causes but a few prominent ones could include

  • Poor System Design – Most projects do not do a adequate job during the architecture assessment phase or skip the process altogether. This by far has been the leading cause of incurring a technical debt early on, something I have seen this over and over again.
  • Lack of Business Process Understanding – The second most common cause of incurring technical debt is a lack of understating the business process for which the IT system is being build. I have seen cases where the IT team has to put in time later on to understand the business process rather than investing time early on thereby incurring higher cost to pay off the debt.
  • Inadequate or inaccurate requirements – Remember technical debt is incurred both willingly and unwillingly. In case the system itself is being designed and built on incorrect or inadequate requirements, there is a strong likely hood of your project will incurring a technical debt during its life-cycle.
  • Lack of coding standards or processes – Skipping standard coding practices or ignoring standards is another leading cause of technical debt.

Managing The Technical Debt Risk

Why is Technical Debt a risk?

If I were to rephrase the question it would be why is technical debt a risk and not an issue ? After all if technical debt has been identified and recognized, it has to be paid off. In other words it has already materialized into an issue and hence should no longer be classified as a risk alone. However for now I am still inclined to manage this as a risk as I am still uncertain on its impacts and the cost to get to pay off this debt. Also often overlooked is the opportunity cost of the technical debt or the ‘positive’ risks or in simple terms just plain opportunities.learn more about Technical Debt by clicking here

Identifying The Technical Debt

Like with other project risks, risk identification is the first step here as well. Your ability to proactively identify the technical debt early on will directly influence your ability to effectively manage the technical debt. Identification can be both proactive and reactive.

  • Proactive Identification – Proactive identification includes process within the project that enable you to look out for technical debts before your project or system actually starts experiencing the symptoms of technical debt. Proactive process include code reviews, architecture assessments and design reviews to name a few.
  • Reactive Identification – Reactive identification is when the project team starts the identification process based on symptoms of technical debt like a constant increase in the number of defects or when you are constantly overshooting your time-lines. Reactive identification could involve process like defect analysis and issue root cause analysis. For obvious reasons reactive identification will most certainly incur higher pay-off costs.

Technical Debt Assessment

Risk assessment traditionally has focused on two key variables, the severity of the risk and the probability of its occurrence. This is mathematically represented as ‘Severity * Probability’. Assessing a technical debt is a little different. The variables that play in here include

  • Quantifiable Debt – The technical debt needs to be quantified. You can do this by assigning weights or by other variables like lines of code. Either way whats is important is have a quantifiable value that can be used for assessment.
  • Pay-off Cost – This should include the actual cost of going back and fixing the code or design as well the complexity and effort involved. For example if the cost of fixing technical debt involves the risk of introducing additional defects that should be accounted as well.
  • The Interest –  Like debt in general, technical debt also accumulates interest. The interest in case of technical debt could include the costs to maintain a system that been coded or designed badly.

The Technical Debt Risk Strategies

Once you have identified and assessed your technical debt successfully it’s now time to have a strategy or a plan to manage these.

  • Avoid The Debt -If you can avoid incurring technical debt altogether in the first place, that would be an ideal scenario, but an ideal scenario is anything but common. That said, there are a certain options that the project team has like adopting for a standardized solution as opposed to a highly customized solutions will significantly reduce the probability of incurring technical debt.
  • Mitigate – There is a three phased approach to this strategy
    1. Mitigate the pay-off cost of the technical debt – The cost involved to fix a bad system design or dirty code can be both high and also potentially add in risk. Based on your risk assessment above you should have a plan to pay off your most profitable debts first.
    2. Mitigate the interest incurred from the existing debts – The interest here is a metaphor to the cost of maintaining a system that is subject to high technical debt.
    3. Stop incurring new debts – As you work on mitigating the impact and the cost of the technical technical debt, you must take or build in steps to ensure you do not incur any new technical debts. So as you work towards managing your technical debt, watch your corners and build this into your process.
  • Acceptance or Retention – There may be a rare scenario where you will probably end up choosing to accept the risk related to technical debt and the associate cost to pay it off. In such scenarios a trade-off is made between the risks associated with the technical debt and the cost associated to pay off the debt. These scenarios could include
  1. When it is NOT profitable to pay off the debt  An example could be where the system in question is due to retire very soon. In such a case it might make sense to accept the cost to maintain the system rather than incurring cost to pay-off the debt.
  2. When there is a positive opportunity cost involved Let’s face it, resources and budget are never unlimited. Programs will be faced with a dilemma where they will have to choose between paying-off a technical debt and an opportunity. This is where the opportunity cost factor comes in. If the cost paying-off of the technical debt is significantly lower than the cost of the missed opportunity of not undertaking another initiative, programs may choose to accept or defer the technical debt.

Again these are rare scenarios, which need to be evaluated carefully before adopting a retention strategy.

Lastly the timing and decision to pay off a technical debt will vary with organizations and departments. This will also depend on the tolerance level these organizations and departments have towards the technical debt as well as the trade-offs involved in paying -off the debt.

Why Project Estimates Fail

Enjoyed the Dilbert?

OK,Many of you might recognize the above situation. One of items on the list of things that Project, Program or Portfolio Managers dread the most are, Project Estimations.(Yes, this list also has scope creep, random changes request and zombies too among other things.). Of-course, it need not be that way. Projects are about estimates, estimating the cost, estimates on schedule or estimating the resources required. Estimation has also been one of the sources of conflict, one one hand the teams have a tendency of padding up estimates in order to give themselves more time, and on the other it is the management and the sponsors who sometimes tend to give unrealistic or overaggressive estimates.

A project manager will need to manage this conflict so that projects can be more predictable and less chaotic. Irrespective of the fact that your project follows a Waterfall, PRINCE2, Agile or anything hybrid in between, the accuracy of your estimates are critical. Accurate estimates are not only the backbone of other planning activities, they are also a factor in determining the feasibility of a project or an initiative before it is undertaken. And yet, often estimates are far from accurate and often fail.Why? lets looks at some top reasons why project estimates fail.learn more about PRINCE2 at https://en.wikipedia.org/wiki/PRINCE2

  • When Estimates Become Commitments or Constraints – Whether you are doing a single point estimate or a range bound estimate for your website, it is important to note that they are still just estimates.They should not be confused with commitments or constraints and they should be used keeping that in mind. Unless this distinction is clear, the results will disastrous. This however, does not mean that estimators throw caution to the wind and produce completely unreliable estimates.
  • When Estimates Are Padded – (refer again the Dilbert strip) Estimates have a tendency to be padded and buffered, while there may be cases where such a buffering might be legitimate like schedule buffers created for change requests, as a rule of thumb padding should be avoided as it creates distrust and the overall reliability of the estimates is compromised. Padding and buffering of estimates are contagious, once padding creeps in, it is a pain weed it out.Why Project Estimates Fail
  • When Estimates Are Not Revisited – Estimates like risks need to be revisited and re-validated as the project or initiatives progresses. The estimate that were done during the initiation, may no longer be current, like a shortage of programming skill might have pushed up the resource rates and mostly would have thrown your estimation off track. Estimates might also have to be revisited as part of the change management process, thus it is essential to carry out a sanity check of your estimates appropriately.
  • When Estimates Are Taken At Their Face Value – Sometimes teams are either over confident or over pessimistic with their estimates. An experienced project manager will validate and reconcile these estimates before using them as a source for planning or any other decision making. Brining in a subject matter expert or referring to historical data are options that can be considered.click here to learn project face value.
  • When Task Dependencies Are Ignored – This is particularly true in case of schedule estimates. Dependent tasks need to be examined carefully before providing a schedule estimate. If it take one developer to complete a tasks in 20 days it does not necessary mean that 20 resources can do the same task in one day. If you have considered fast tracking or crashing while estimating, they need to be validated with any dependencies that may exist.
  • When Estimates Are Not Communicated – Like with other project documents and deliverable, estimates also need to be communicated. An estimate without the buy-in from the respective stakeholders is worthless. Also unless estimates are communicated, there is a strong likely hood that any risks associated with the estimates will also go unnoticed.
  • When It Is Just a Guesstimate – Estimates that are not based on historical project data, industry standards or any other generally accepted rule of thumb is not an estimate, it is just a guess. Relying on a guesstimate for your planning and decision making is of-course, a sure shot way to kill the project.
  • When You Forget The Math – No matter how lean or agile your management methodology is, when it boils down to the accuracy of your estimates, a little number crunching can go a long way in increasing the reliability and accuracy of your estimates. For instance when you do not have similar or reusable components to base your estimates, a simple PERT formula can help out in arriving at a more reasonable number (Mean = (least+4* Most likely +Most)/6). If you have much more at stake and need more accuracy you can use the COCOMO algorithm.
  • When Estimates Are Done In Silos – Last but not the least, estimation is not a single personal responsibility, though a single may be responsible for consolidating and communicating the estimates. A project manager or any other person single should not be doing  estimation for the entire project alone. Estimation is about getting consensus. The more involved the team is in gathering the estimates, the better are the chances of your estimates being accurate. Silo estimates neither have the accuracy nor the team buy-in, they are just another recipe for project disaster.

Have your own tips on project estimation or reasons on why estimates fail? Drop in a comment.

The (Agile) Email Why Project Estimates Fail

Email Why Project Estimates Fail

Despite the fact that email ranks number one on the list of top time suckers, it may not be practical to completely avoid email. But is there a way we can minimize the damage and turn it into an asset? Yes – with a little common sense and some basic rules that I have been diligently following. Taking a clue from the agile manifesto, I decided to put them in the same format and set-up a my own email manifesto which I solemnly swear to abide by and hopefully will be able to influence a few good people to adopt the manifesto as well along the way.

The Manifesto

  • Will explore and exhaust all other communication channels before choosing to email. Including but not limited an in person communication, a phone call or an IM chat.
  • Check and process email only at specific times of the day or better specific days.
  • Will maintain a zero inbox daily or as often you check and process email.
  • Use email just as a communication tool. Email shall not be used to store and retrieve information as document management or as a task management system.learn more communication tools at https://www.scu.edu/mobi/business-courses/starting-a-business/session-8-communication-tools/
  • All email will have a clear and a specific subject and the content in the email will stick to that subject and only that subject.Email Why Project Estimates Fail
  • Will be mindful when including attachments in email. Including both type and size of the attachments.
  • Will NOT SPAM, will be mindful when doing a ‘Reply All’ and when forwarding email messages.
  • Emails threads will be limited to 5 or less. If a subject cannot be covered or resolved within 5 email threads it will be taken off to a different forum.click here to learn email threads.
  • Will include the only the people whom the email is addressed to in the TO section. Will use the CC section only in rare cases and will NOT use the Blind Carbon Copy (bcc) option.
  • Will not be disrespectful,abusive,coercive, dishonest, manipulative or misrepresent facts in my emails.

Live Manifesto

In the spirit of keeping this manifesto live and flexible your feedback will be very helpful. Would like to hear if you agree/ disagree or want to add in to the manifesto. If nothing else signing the manifesto would be cool as well

Lessons from Agile – The Minimum Viable Product

Last few months I have been fortunate to be leading complex enterprise initiatives using the agile framework that have in the past been delivered successfully using the traditional waterfall model .Thankfully due to a load of awareness created by the Agile community in recent times, convincing our sponsors and stakeholders to take the agile route was the easiest.The most challenging area however was planning the sprints and the overall release planning.

No matter how much sense it made to the IT team on how we structured our sprints based on technical features or capabilities we still had the challenge of getting our key stakeholders i.e the business testers to participate in our sprints. So back we went to the whiteboard to figure out the missing link and then there it was – the sprints either independently or as whole for the release were missing a viable product that would add business value. Yes we were bringing in tons of data and writing really complex ETLs and interfaces to extract and manipulate the data, but the actual business functionality was getting released in future releases and further planned out sprints.In an ideal world we still would have been able to succeed with our current planned approach, however in the real world we could sense the risk of our stakeholder’s patience running out. So we replanted our sprints and releases focusing the minimum viable product (MVP). Learn more about ETLs and interfaces at https://www.labkey.org/Documentation/wiki-page.view?name=etlUI

What is a MVP

A MVP is a subset of the scope or the feature list that has a tangible business value that can be used by the end users, client or customers. The way you define and identify a MVP will vary with the type project or product. However what is constant is that these are a minimum list of features that justify the investment of time and resources for the sprints early on. A minimum viable product is different from a minimum desirable product. A minimum desirable product goes beyond viability to include more scope and features from the requirement or scope document. Ideally you should plan a agile release or sprints with a MVP progressively moving to the MDP state in the next iterations that would deliver maximum business benefit and customer delight. Did I hear someone mention scope creep? , I will pass it for now for a different discussion.

Lessons from Agile – The Minimum Viable Product

How do you identify the MVP

Identify the MVPDon’t start building or executing your sprints until you have identified your MVP. The below 5 step process to identify and define a MVP worked for us

  1. Identify stakeholders who are responsible for defining the MVP. Based on your project, it can be either the product owner or the business sponsor along with any other key team members. What is important is that this individuals or the group is identified so they can make decisions around the MVP.
  2. Use the scope document or the product backlog as the starting guide and run this with the sprint teams to plan out the MVP for your sprints or releases. An MVP technically should be a subset of this scope document or the product backlog. if this is not the case then you need to go back and get your product backlog and /or your scope document in order.
  3. Limit the number of interdependent features that you include in your MVP. Focus on the viable, but keep the minimum in mind. Having too many interdependent feature will limit your ability to do so.
  4. Prototype your MVP to get stakeholder feedback before your start your actual development, build and execution. In certain cases, having multiple MVP prototypes will help stakeholder choose the most suitable one.
  5. Align your MVP with the strategic business goal that the initiated project or product supports. You need to be able to build upon this MVP as you move forward with your sprints and releases. Yes, an MVP may be a moving target, but you should not have to redefine your MVP from the scratch.

We are still a long way to go with respect to perfecting this process, however with a couple successful releases behind us, we feel confident that our approach works and excited as we move forward with it. What we learned in the process was that the concept of MVP assumed greater significance as we roll out projects and initiatives using an Agile framework.

Use a Responsibility Matrix to fight Project CHAOS

Project Planning

Project teams, specially those working on large projects or programs with a lot of cross functional interactions, its common to have ambiguity to creep on the ownership of specific deliverable. In such cases a Project Responsibility Matrix can be used as an effective tool to reduce CHAOS by creating a clear accountability rules for the project deliverable.

A responsibility matrix also know as the RACI (Responsible,Accountable,Consult & Inform) or the RAM (Responsibility Assignment Matrix) is a tabular representation of the tasks , phases or deliverables within a project along with their  various degrees of responsibilities with respect to the project team members.

Each project task or deliverable is represented as a row in the matrix, whereas the project team members or roles are represented in the columns of the table.Typically in small projects it may be possible to have individual team members represented in the columns but it is generally a good practice to have the distinct roles in the columns.

Elements of a Responsibility Matrix

A responsibility matrix can be implemented in different ways that best suits an individual project and website design. However there are some basic common elements which each responsibility matrix must have

  • Responsible (‘R’) –  This will refer to a person or a role which is responsible for executing the task.
  • Accountable (‘A’) –  This will be the person will be accountable for the specific deliverable. It is critical to have one and only one person to be accountable for each specific deliverable.
  • Consult – (‘C’) – These will be the person / group will be consulted in the process of executing the task or delivering a project deliverable.There can be multiple people who can be consulted and these interactions with them are critical for the deliverable.
  • Informed (‘I’) – This are the people who will be kept informed on the progress of the deliverable as the project moves through the execution cycle.

There may be cases where the same person or a group is both accountable and responsible for executing the tasks for example a project manager is both responsible and accountable for publishing the project time-lines, in such cases you may have more than one attribute in a single cell. learn more about project management at http://www.aroundthechaos.com/why-project-estimates-fail/

Uses of a Responsibility Matrix

  • Communication Tool – The responsibility matrix servers as a great communication tool for the stakeholders of the project as it provides them with visibility of the deliverables and the people who are accountable for those. It also defines the engagement rules for Interactions between cross functional teams as well as team members.
  • Conflict Management Tool – Since a responsibility matrix is the single source of truth for identifying the ownership and accountability it can act as a tool to avoid any potential conflict that arise due to ownership and accountability as well as resolve conflicts.
  • Address Overlaps – A responsibility matrix can also bring out any overlaps of responsibility that may exist in a project. These overlaps must be addressed to optimize project execution.
  • Project Status Assessment – Although not one of the direct benefits of a responsibility matrix, it can be used by the project manager to analyze the project and uncover any hidden risks that may arise out of any complex deliverables represented in the responsibility matrix.

Best Practices

  • Publish It – The sooner in the life-cycle of the project you have the responsibility matrix published the better it is. Ideally it is expected to have one created during the analysis / planning phase.
  • Single ownership – Each task in the responsibility matrix MUST have a single owner. In other words there must be only one accountable person for each task. You may have multiple people responsible for executing the task but the accountability should be single , so as to be clear of any ambiguity.
  • Tie Back to the WBS and Project Plan – You should be able to ideally tie back the responsibility matrix back your porject plan or the WBS (if it s detailed enough).
  • Decompose – If you are dealing with large projects or programs its often works well to have multiple responsibility matrixes created based on your Project phases.
  • Legends – Last but the least, It is always a good practice to include a legend of the various elements you have used in your responsibility matrix.

Have any tips on effectively using the responsibility matrix? Feel free to share.