Lessons from a struggling software project – Step 1: Identify the failure scenario

Struggling ProjectsIn our Fractional CTO™ practice we often help distressed software development teams in the middle of a struggling project, or right after one has failed. Regardless of the size of the organization or project, the failures are usually caused by tensions between the definition of the end result and the process by which the team attempts to accomplish it.

In this series we will explore our approach to identifying and addressing project failures in the hopes of enabling you to capitalize on our lessons learned. We break the process into four steps; identify the failure scenario, assess the indicators of project risk, identify the root causes, and then formulate a remedy.

Step 1: Identify the failure scenario

Every new situation requires us to first identify the type of project “failure” the client perceives they are dealing with. We want to identify themes in order to build team consensus and understanding of the issues from a strategic point of view. Later we will create an action plan to resolve the issues. Typically, project challenges fall into any of the four categories described below. If you have ever struggled with a software project these categories may sound familiar.

Financial disaster

There are many reasons why a project may feel like it is sucking money. So when it becomes clear management views the project as an endless stream of unplanned costs we focus on that. This could be a lack of cost controls, poor project management or software quality and practices, or a variety of other challenges in the SDLC that we will try to identify in a later stage of investigation. Usually this can lead to other serious problems and significantly erode trust and communication and force bad choices. For instance, you don’t want to throw good money after bad but replacing the team or changing the project goals may make things worse. It’s important to get to the root of the problem quickly before this high burn rate leaves you with no good options. When this happens project termination, or abandonment is often the result.

Unending scope creep

The project requirements continually change resulting in a seemingly never-ending project with more and more features but no sense of completion. In some cases there may be no releases, just a steady stream of new requirements. A variation on this is a sense that the software isn’t “perfect” so it is either never released or the release is never considered worthy due to constant tweaking. This could be due to poor quality in any stage of the Software Development Life Cycle (SDLC) combined with unrealistic expectations. There is simply no clear strategy for calling the project “done”.

Over the course of these projects Management will often ask “Why can’t we ever ship anything?” or “This seems simple, why can’t we finish it?” It is common to hear the development team in these situations complain that, “Every time we show Management/The Customer our progress they change what they want.”

The result will often be that Management becomes frustrated with the lack of a released product and out of control costs. Meanwhile this endless drip of requirements can lead to low development team morale since they want to feel accomplished. What’s worse, this deterioration of morale can lead to a lack of project commitment since the team will feel like they can’t finish anything and that feeling slowly becomes the accepted cultural norm.

Bitter endings

The team finally hits their milestones but the project is not viewed as worthwhile upon completion. The perception may be the overall costs were too high, “nobody” is finding the new features helpful, it’s possible the original intent and need has been forgotten. Even worse, the resources, who are now burned out, could have been better utilized. As technical leaders ourselves it hurts to recognize the tremendous amount of energy and creativity that went into a project which when finally completed no longer represents core business value. We find this more often in non-agile projects, however even projects utilizing tight iterations can suffer from this disconnect when there is a lack of real product ownership and an uncommitted team that doesn’t challenge weak requirements or focus on consistently delivering value.

Abandonment

When a project fails it may end up getting turned off, resources reallocated or let go. For a small company this could be the end. For a larger company it could be the end of a strategic vision or it could be wasted money followed by a reboot with a different team or approach. Abandonment is the result of not identifying the signs of a project at risk and taking action soon enough. The mistake many companies make with this type of result is they don’t learn enough from it. Taking the time to really do a detailed and constructive analysis of what happened can be invaluable, in fact, in the long run it could be more valuable than the promise of the original project. If an organization learns sufficient lessons from their mistakes they can become a stronger and more effective organization. So while this may be the worst of all outcomes for a project it doesn’t have to be a complete waste for the company.

Project ManagementThere are of course many types of failures but these four general scenarios cover the majority of situations we help to unwind and improve. They are also in the back of our mind whenever we are helping to launch new project initiatives as serious risks to avoid. Understanding where the project stands and having the team come to consensus is the first step in fixing the problem or avoiding it in the future. In the next installment we will examine some of the underlying indicators that help us clue in where the issues are percolating so we can later hone in and address them. These key issues are also important areas for new teams to learn to avoid and address quickly so their project doesn’t end up in one of the failure scenarios.

If you have any war stories and observations on this topic we would love to hear from you. By sharing our experience we can all improve our process and deliver high-quality solutions.

 

Commitment to Process – Key Quality of Successful Development Teams

CommitmentOne of the benefits of the work we do at NeuEon is that we have the opportunity to work alongside some very talented developers.  Yet, more often than not, we find that one of the reasons most products fail and why most development teams are not successful in meeting their objectives has nothing to do with their ability to write code. One of the reasons most teams fail is because they do not follow a disciplined process for building production quality software. The actual process a team subscribes to is less important than the fact that they have one. You could argue that one methodology is more effective than another.  We happen to like Scrum, but there are others that are just as good.

Once the team determines the methodology will follow, it is imperative that they commit to it and hold each other accountable to it.  Let’s use the Scrum process as an example.  The knock on Scrum is that it is too rigid.  The reality is that Scrum has very few rules, however the few that do exist must be followed with the utmost discipline or else the process and the team will likely fail.  Scrum calls for a select number of meetings that happen in regular intervals.  These events include:

  • Sprint Planning Session – occurs at the start of each development sprint to allow the Product Owner to communicate the priority of the stories that the development team need to complete during the sprint.
  • Daily Standup – occurs every day for upto 15 minutes in which all members of the development team answer three very specific questions – 1.) What did I complete yesterday; 2.) What do I plan on working on today; 3.) What roadblocks do I have that I need help removing
  • Sprint Review – occurs at the end of the development sprint.  The development team demonstrates the work that was completed in order to give the Product Owner and stakeholders the opportunity to sign off that work was completed as specified.
  • Sprint Retrospective – occurs immediately following the Sprint Review to allow the development team to discuss how the team can improve.  During the retrospective teams ask 1.) What did we do well – what should we do more of?;  2.) What didn’t we do well – what should we do less of?

There are obviously many other principals of the Scrum development methodology such as story estimation, acceptance criteria, backlog grooming, etc., however for the purposes of this article we are going to focus on the four mentioned above.

The interval in which these meetings occur may vary from project to project depending on the length of your sprint.  What should not change is when they take place.  The Sprint Planning Session takes place on the first day of the sprint, and the Sprint Review and Retrospective occur on the last day of the sprint.  These meetings must be scheduled as recurring events on the team’s calendars.  Successful teams hold each other accountable for attending every meeting and coming prepared.

During the course of every development sprint emergencies occur, and priorities are challenged constantly.  What must stay constant however is the commitment to the process.  Early in the process it may feel as if the “overhead” of the process is getting in the way of completing tasks, but the time spent is essential for long-term efficiencies.  A common statement we hear is, “I can’t make it to the planning session because I have to finish a deliverable for this afternoon.”  This is unacceptable.  Good teams create a culture of that puts the process as a top priority.  It is the responsibility of each individual to plan their availability and forecast deliverables around the commitments of the process.

When you join a Scrum team you commit to the team and the process.  The meetings are critical to the success of the project and in start-ups, the business.  Early in our involvement with new teams, we ask them to look around the room and count up the hourly rate of each team member to put a dollar amount to the meeting.  This inevitably gets the attention of  the business owner when they view it from a financial perspective.  In many cases these meetings cost the company thousands of dollars.  When individuals and the team do not approach these meetings with the necessary commitment and diligence, it has a negative impact on the business not only on productivity, but financially as well.

On Being Remote and Not

We subscribe to many of the points outlined in “Remote: Office Not Required” by Jason Fried and David Heinemeier Hansson.  Especially the concept of getting together in person from time to time.

Remote: Office Not Required

Remote: Office Not Required

In January we had the chance to meet for our annual company meeting. It was a chance to have team members that have only met via Google Hangouts and GotoMeeting to meet in person. Our annual gatherings tend to be set up similar to a scrum planning day. There’s a bit of retrospective about the year that just passed, analyze what works and doesn’t work and review the results that we have achieved. The other half of the meeting is dedicated to planning for the upcoming year in which we look at goals and objectives and agree on what we’re committing to as a team. We also review any changes in our services as well as internal operational items like employee benefits. This is a great time to get to know each other and share a meal or two, and this year was no exception. These annual events have been so successful that we are exploring other ways to get together more frequently throughout the year.

In addition to our company-wide gathering, our leadership team took the opportunity to do our quarterly off-site planning session this past weekend. This time we were fortunate to be in Lake Placid where the weather was conducive to both outdoor activities and getting some work done. We set a theme or topic for the weekend that we want to tackle and discuss in detail – this weekend was all about marketing. This served as the topic of conversation throughout the weekend – as well as in the car and even on the ski lift.

In the past few weeks, it has become even more compelling to be a 100% remote-only company. Those of us in the Northeast of the United States and more specifically in Eastern Massachusetts have been subject to a crippling amount of snowfall. This extreme weather has made virtual meeting technologies a critical investment for us and reinforced our belief in our “Remote: Office Not Required” philosophy.

 

Happy Holidays

We appreciate your business!


We’ve been getting lots of calls, emails and text messages about this commercial…. yes it is the leadership team at NeuEon (@ 12 seconds in).

Thanks to our friends at VistaPrint for running it again this year, Happy Holidays!

 

.NET goes open source – what does it mean for you?

You may have been a little distracted yesterday by the historic landing of Philae on Comet 67P, so don’t be too hard on yourself if you missed Microsoft’s announcement that it’s open-sourcing the .NET stack and making available a free, relatively-full-featured version of Visual Studio. And it’s true; the .Net Foundation Github page now features links to repos for .NET Core 5, ASP.NET 5, the Azure SDK, and several other projects. You can also now download Visual Studio 2013 Community Edition, which has many of the features of Visual Studio Professional.

I’ll add my voice to the crowd shouting “It’s about time you did that!” A free, non-crippled IDE removes a major barrier to entry for use of Azure services and Visual Studio Online. Now that the full tool pipeline is available at reasonable cost, Azure becomes an option for a broader audience, especially for open-source development. However, for many existing Microsoft development teams, Community probably doesn’t provide much of a benefit. Some teams might be able to do some more of your cross-plaftorm mobile development in Visual Studio, but the license terms for Community restrict its use in for-profit endeavors. This demonstrates that Microsoft is not yet ready to walk away from their “developers as profit center” mindset, and will continue to limit Microsoft’s ability to compete with other platforms.

Cross-platform .NET could make Microsoft more of a presence in cloud services, but that’s more potential than reality at this point. I appreciate the tacit admission that Windows can’t compete with Linux on any non-desktop platform, but the tools to actually build and run the .NET CLI on a non-Windows platform don’t yet exist. Once they do, they have the potential to reduce infrastructure costs for any .NET-based development team. Windows-only organizations will have to adapt to a heterogenous environment to take advantage of those savings, and that will be a slow process.

In summary, if you’re trying to decide whether to go .NET or not for a project that will launch in the next six months, the announcement probably doesn’t influence your decision much. Open-source projects now have access to a free-as-in-beer, capable version of Visual Studio, but you will likely still need one of the paid versions in order to do commercial development. You’ll also need to deploy your .NET code on Windows for the foreseeable future, unless Mono can run your project and you’re willing to give it a try. And the terms of the rest of the tool chain for web apps (TFS, IIS and SQL Server) haven’t changed. .NET is still a hard sell for teams that don’t have an existing Microsoft investment.

 

A great day and a great cause

We were proud to sponsor this year’s Walk to Defeat ALS event in Boston.  We had a fantastic team of walkers and raised $13,125, the highest team amount raised that day.   The overall event raised over $400K!

Thanks to everyone involved.

2014 ALS Walk Boston-9081

A Watch Guy’s Thoughts On The Apple Watch

On Tuesday Apple announced several new products including the Apple Watch. Apple’s giant ecosystem has the ability to move markets and affect the lives of software developers world-wide. This watch has the potential to open up new markets and create a new segment of the “app economy”.  Apple Watch developers will soon be popping up. There are many things to think about when developing for this form factor and there will be debates for a long time on the usefulness and future of the product. Apple has a history of disrupting markets and even putting a few developers out of business. Just ask anyone who built a calculator or flashlight app… So while I continue to ponder the long-term implications of connected wearable devices and the replacement of credit cards with a swipe of my  Apple Watch and Apple’s new Apple Pay system, I started to wonder what will hundreds of millions of iPhone users eying the Apple Watch do to the traditional watch market, not to mention the current “smart watch” market. Well, along came this article from a watch enthusiast that I felt answered this question fairly well…

A Watch Guy’s Thoughts On The Apple Watch After Seeing It In The Metal (Tons Of Live Photos) — HODINKEE – Wristwatch News, Reviews, & Original Stories.

 

http://images.apple.com/v/watch/a/design/images/hero_leather_large.png

 

The Future of Point of Sale

Great presentation this morning from Sid and Sharise from our client Snows Home and Garden at the Cape Cod Technology Council @CapeCodTech

 

Software/App Company 101

This is great article about one of our clients about how she started her company and launched her first app, congrats MJ!

http://www.burlingtonfreepress.com/story/money/2014/07/24/vermont-mobile-phone-apps-wellness-teens/13067789/

 

WEBINAR: The Evolving Role of the CIO

Hear how Cloud technologies and Big Data are causing major changes to the CIO role.

Are Big Data and Cloud Services a threat to CIOs? In the past, CIOs have served primarily as custodians of IT infrastructure. Big Data – together with social, mobile, and Cloud (SOMOCO) computing – throws the value of legacy IT infrastructure into question and undermines the traditional authority of CIOs. For corporate CIOs, getting comfortable with IT infrastructure and services outside their four walls and raised floors, will require reaching beyond the traditional comfort zone of IT. It will require a multi-disciplinary approach including business management, math, and behavioral science with far less emphasis on traditional IT practices. And add to the mix, the mindset of a venture capitalist!

Click link to view http://www.everynetwork.com/thought-leadership/overview?upcoming_webinars=true

Takeaway: 
Understanding and preparing for the new roles and responsibilities of tomorrow’s CIO.

Turning talk into action – What we will cover: 
The IT role through a different lens
How Cloud technologies are shifting decision-making and how CIOs can add value
Big Data: who will be responsible for harnessing its potential?
The CIOs department as a profit center

Who should watch? 
CIOs, CTOs, IT managers, CFOs and business managers responsible for their organization’s technology.

Speaker – Peter Karlson
Peter is the President/CEO of NeuEon Inc. Peter is a serial entrepreneur with experience in bootstrapping, strategic investments and angel financing. NeuEon specializes in providing strategic guidance and advice to entrepreneurs and established organizations looking to create and use technology more effectively.  As a former chief technology officer for two Massachusetts based technology services firms, Peter has gained diverse industry expertise in healthcare, non-profit, manufacturing, pharmaceuticals and publishing.  He has been involved with developing Internet technologies since 1991 with the creation of the first Internet browser, the InterNavigator™

Webinar presented in conjunction with EveryNetwork Inc.