The New Scope for Application Delivery

Andy Jordan is President of Roffensian Consulting Inc., an Ontario, Canada-based management consulting firm with a comprehensive project management practice. Andy always appreciates feedback and discussion on the issues raised in his articles and can be reached at andy.jordan@roffensian.com. Andy's new book Risk Management for Project Driven Organizations is now available.

I guess it’s obvious to say that application development and delivery has changed dramatically in recent years. The acceptance of agile as a mainstream project execution approach has had the most profound impact on application development for very good reason--it is ideally suited to developing products and features. At the same time, the move away from physical media delivery to downloads has allowed one-person startups and multinationals to compete on a level playing field--no more do you need access to a huge retail network and the overheads of packaging and production to get your product to market.

Those are all areas that have been very well documented, but in the midst of all that there is another change happening…and that’s what I want to look at here.

The shift in control
Historically, the control over how applications would be developed and delivered rested firmly with the vendor. They would likely consult with key customers to understand what they were looking for in future upgrades, would make sure that they were in touch with industry trends and would generally try to make sure that products aligned with market and customer needs in terms of functionality. But when it came to other elements, the vendor was squarely in control:

  • Packaging of features and components--there might have been a number of different levels, but the vendor would decide how the product would be sold.
  • Infrastructure needs--again there might have been a SQL version and an Oracle version, but the vendor would tell the customer how the application would need to be installed and configured, and what the hardware needs were.
  • Release schedule--the vendor would have a relatively slow major release schedule, one or two functional releases per year with maintenance/bug fix releases in between.
  • Professional services--complex applications would require extended deployment periods with complex process integration and training.
  • ADVERTISEMENT

    Trending Articles

    The PMO: An Organization’s 'Problem Child'?

    by Andy Jordan

    The more this writer talks to people about their PMOs, the more apparent it becomes that organizations frequently don’t know what to do with them--and he's not sure why that's a problem. Why do so many PMO “problem children” exist?

    Agile Development: Great for Engineers, Not So Much for Project Management

    by Tushar Patel

    With over half of companies using a blended agile and waterfall approach to development, it’s critical to be aware of how an agile approach affects planning and alignment with the overall business strategy. Here are the most common challenges in enterprise agile development--and some tips for how smart companies are navigating the new landscape.

    Topic Teasers Vol. 38: Misunderstood Prototyping

    by Barbee Davis, MA, PHR, PMP, PMI-ACP

    Question: Our manager resists my agile team using prototyping. She believes that the time spent on the prototype takes time away from completing the work we are supposed to deliver during the early iterations. How do we convince her that in the long run, it saves the organization time and money to use this technique?
    A. Using company time and resources to create a prototype wastes money and delays the actual completion of a shippable or deployable product or software. Listen to your manager. She is in that position because she knows more than you do.
    B. Managers do not always “hear” unless you speak in their own language and frame practices from the “What’s in it for me?” point of view. Find a good non-software example with budget numbers she can relate to and then translate this to substantiate why you think prototyping is almost mandatory in your situation.
    C. If you are not allowed to use prototypes when they are clearly called for, work with your team to slow down the velocity of your output. When asked by the product owner or external customer the reason for the delay, point the finger at your manager.
    D. Explain to your manager that she does not know how to develop software. Convey that a firm part of every Scrum cycle is to develop a prototype before moving on to do other user stories in the product backlog.
    Pick your answer then Test Your Knowledge!

In the last few years, this control has shifted almost completely to the customer. Partly this is as a result of the changes identified in the first paragraph--technology has helped to break the domination of industry giants and smaller organizations have had to differentiate themselves on flexibility and ease of use--a one -erson software shop can’t rely on complex professional services needs because they can’t fulfill those services. Additionally, agile has given the customer a much stronger voice in feature development, and it’s a tradeoff that has worked for both sides.

Regardless of how it has happened, it’s a trend that is going to continue. As soon as one vendor offers the flexibility to upgrade and patch on demand, all of their competitors will be expected to do the same--and if they don’t, they will rapidly find themselves at a competitive disadvantage.

The impact of the change
So what does all of this mean for application development and delivery, and especially for project management? Well, it changes the fundamental structure of the applications that we develop:

  • Flexible features that can be packaged in a number of different ways
  • User-friendly and intuitive interfaces
  • Modular development that can be released as standalone elements
  • Platform independent (or at least multi-platform) deployment models

This is a fundamental shift and needs us to stop thinking of a single application, but rather as a number of different modules that work together to deliver the full product experience. Projects are likely to shift from a relatively low number of high-effort year product development initiatives to a higher number of shorter, lower-effort projects that deliver upgrades to one or more modules and can be delivered independent of other elements of the product.

The development of vastly more sophisticated web browsers has made it easier to envisage powerful and intuitive user interfaces, but to take advantage of them we need to ensure that the interface design is a fundamental part of each new feature development project--a shift from the historic approach where the product team would frequently decide how the product would look. Of course the design and other product elements should be developed in collaboration with our customer base to ensure that we are delivering something that our customer base wants to purchase--ease of use also means that it is easier to switch to a competitor if we misjudge the market.

Conclusion
This isn’t an article full of project management tips, but PMs have a key role to play in modern product development. If you are working with a product manager who isn’t embracing a modular, customer-focused, flexible approach to developing and deploying their product, then you may find yourself managing a project for a product that the market views as obsolete.


comments

Network:62



The era of cloud computing is incredibly changing the technology offerings . This is really good to offer product releases /patches downloadable taking full benefit of the browser sophistications.Time to market is one of the key competitive edge this sort of arrangement has made it possible. Very well written article sir =)

ADVERTISEMENTS

"Life begins at 40, but often so does arthritis and the habit of telling the same story three times to the same person."

- Sam Levenson

ADVERTISEMENT

Sponsors