Much discussion has been going on surrounding web applications to serve the project management community. Before I continue my discussion, however, it is instructive to define terms.
When I talk about project management I’m not talking about a few dozen activities in a schedule that is resource-loaded. Instead what I mean is the ability to service industries that are engaged in complex project management. Typically such efforts involve a range from hundreds of thousands to billions of dollars, dedicating resources that stretch for several years. The underlying applications tend to be focused on specialties in the project management field: cost, earned value, scheduling, risk, technical performance, project financial management, change order management, and others. This tends to involve millions of records and, sometimes, the use of more than one repository. Thus, when I ask the question in the title it becomes clear that selecting a set of apps from an on-line marketplace is not going to cut it.
Now that we have focused on our definition of project management in this context, the next term that requires definition is: what is a web app? The classic definition is that it is an application that is created in a browser programming language and utilizes a browser to deliver its functionality. Classically HTML or HTML5 is used, perhaps Java and some other methods, but you get the idea. When we approach this issue using that very limited definition then the next question inevitably posed to the customer is: what functionality can you live without? WinForms and other recent .NET innovations to deliver more functionality and flexibility to users are not available using these traditional web languages, not even the highly touted HTML5.
There are also issues that go beyond limitations on functionality. For example, there are issues of compatibility. If you’ve designed an app in HTML5 you may have effectively eliminated a good portion of your target market because they do not use a compatible browser. Thus, not only are HTML and HTML5 applications limited in terms of functionality and flexibility, but the class of users is further segmented based on the version and type of browser being used.
Many of these constraints relate to security which, given the recent plethora of hacking events, is becoming the overriding issue in our field today, especially as it relates to sensitive information. This concern applies to the limitations in security in web applications, which many times are not written to support requirements such as encryption at rest, point to point encryption, single sign-on and authentication, and other methods of blocking unauthorized access.
Given that there are real problems, even today, in delivering web applications to service the complex project management market, what is the driving force behind many organizations seeking web applications? The idealized economics that seem to be driving a serious look at web apps, even if only to seek out “next generation” applications with promise, are the need to reduce maintenance costs at the desktop, centralized configuration control for bug fixes and upgrades, reduced disk utilization at the client, and cross hardware platform compatibility. I call these economics “idealized” because they fall short of the reality of what is currently available in web applications today, though there have been great strides and there is great promise there.
But the tradeoffs are significant. Not only do they extend to limitations on functionality and security but also limitations on the enterprise deployment side. It is one thing to develop an app on the web that essentially replicates a smartphone app for a limited class and number of users, and another to require integration of functions that will require access to multiple data repositories and serve different objects involving millions of records to different classes of users. Diminished performance is also an issue in this scenario, subjecting response times and the ability to effectively work to the vagaries of both internal and external bandwidth, and ISP uptime.
Thus, the solution, I think, is to find alternatives that currently meet many the economic drivers that are behind the inquires in seeking web applications while sacrificing none of the value that was essential to defining the preferred solution in the first place.
One such example is to use client-server applications served using terminal services through a browser that not only provide essential security but also provide maximum functionality and performance while also providing for centralized configuration control through one-click solutions. In this alternative, there is some flexibility in determining how fat the client will be and whether any local resources can be used to provide maximum flexibility, functionality, and performance. When deployed within the customer ecosystem, limitations on access of disparate data are overcome.
A second alternative is to use this model to provide a web thin-client solution that delivers some files to the client and which may also utilize some client resources to maximize performance, and overcoming the limitations of bandwidth. Once again, within the organization’s ecosystem, this solution provides all of the advantages of a traditionally-defined web application while also maintaining the implicit advantages of a fat client.
A third alternative is to deliver fat client functionality using cloud services, but with this comes the disadvantage of limitations in accessing disparate corporate repositories. In order to maintain security, terminal services is the preferred method of delivery, even if achieved through a browser. Thus, the other advantages listed above for terminal services in a browser also apply to this solution.
Finally, a fourth approach can be deployed that meets the economic necessities that web solutions tout but do not yet fully achieve. That is to select any of the above alternatives for users that require full functionality and all of the flexibility found in the preferred solution, and for specific limited functions to be delivered via the web to particular classes of user, preferably to support portable devices such as tablet computers. This concept extends the distributed processing model while also maintaining sufficient security and configuration control. But this concept goes well beyond reporting tools that are essentially glorified PowerPoint in a browser. Under this alternative approach, the limitations of the HTML solution will be overcome by providing for distributed transactional functionality in the field. Thus, functions are assigned where they belong: full functionality, control, security and flexibility in the office, and augmented reporting functionality–where needed–from those operating off-site or in the field.
Life, Project Management, and Everything 