A Proposal for Advanced Application Development

by

Griff Jay

Conundrum #1 Youâve been tasked to do a needs assessment for a complex system. It is multi-tiered, with multiple departments on each level and with multiple applications within each department. There is interaction and shared data between levels, between applications, between departments. There are summary requirements for the Executive level, more detailed info requirements for the Management level, specific instructions for operational support, and delicate issues and requirements for disbursing information to the public. A lot of solid information is known among the key players in various departments. Certain commitments are in place, time frames are in place, priorities are understood. However, there are huge gaps in what is known, more accurately huge holes of what is not known. You have to give a quick rough cut to both your CFO and the client CFO within days. In three weeks you have to deliver a project outline to the CFOs that contains a budget, schedule, and resource requirements.

Conundrum #2 An effective project team that could handle the assignment described above has to contain three sets of skills: 1) advanced technical talent, with experience at having done similar jobs, attuned to new technologies and development paradigms, 2) advanced applications expertise, knowing the science of the application and the jobs of the end users, and 3) advanced executive talent, which knows the business and financial model of the client and can interface with their decision-makers. In sum, three people each with about 20 years experience, a talent team that brings a combined 60 years experience to the problem. And quite frankly, a team that is exceedingly difficult to field. You canât find them; you canât afford them; if you could put together such a team, you can only send them to one locale at a time. What you can more reasonably expect to be able to pull together is a team of three bright young professionals, with solid credentials, good degrees, 5-8 years experience, and good heads on their shoulders, who can think. What you need for this team is a framework for collecting the information and the backup of those experts from the 60-year team, via long distance mentoring.

Conundrum #3 You are a small consulting firm with about $5M per year revenues generated by and supporting about 45 employees. The firm succeeds with perhaps 7 major client-directed projects, all fueled by the dedication of talented professionals, their stamina, and good intentions. What is the model that allows you to grow your company from $5M to $50M per year? That would require 42 such projects, with probably 240-260 employees. Now the situation is so complex that it is simply not humanly possible to manage it by stamina and good intentions. To make this order of magnitude leap, there must be a business and technical model in place that coordinates these activities, manages this complexity, and supports the business at every stage from executive to operations, from sales to bookkeeping, and most importantly from development to delivery to support.

Conundrum #4 How is the development team supposed to ramp up on the project if they havenât been part of the spec team? How can they talk the same language as the client and the end user? and produce what the client was sold? How to avoid the disconnect and expense of re-ramping up?

Conundrums #5, #6, #7, #8, ... How to track progress? How to spec the follow-up while the initial phase is still underway? How can accounting know when to bill for milestones? How can project information and intelligence keep being incorporated into the design and implementation without disrupting the flow and without the project calcifying around the original idea?

I searched for an appropriate word for the business and technical problems cited above in the preface? The best one is not a word of every day use, and it is probably only known to English majors and columnist James Kilpatrick. But it describes the problems best:

Conundrum: 16^th century Oxford University; early sp. quonnundrum 1) a problem for which there is no satisfactory solution, 2) any puzzling question or difficult problem, 3) a riddle whose answer contains a pun (Ex. "Whatâs the difference between a jeweler and a jailer?" "Once sells watches and the other watches cells.")

Ok, forgetting definition #3 and leaving the jokes to a travelling juggling and vaudeville act, the first two definitions are what I was looking for. But are these business and technical problems really unsolvable? Are they like the cartographerâs map projection which at best introduces distortion and settles for compromise.

Since if I accepted definition #1, then there would not be any reason for this white paper, it is a good bet that I do think thereâs a solution to these problems, and I endorse definition #2. That the problem is difficult should not be a deterrent ö it just means that a new set of tools needs to be brought to the fray.

I propose that there is needed a new toolset, which I refer to as Rapid Project Spec, or ProjSpec for short. ProjSpec is a set of applications which allows the analyst (note not programmer) to encapsulate objects, name them, record attributes about them, rank objects, categorize them, weight them, link objects, assign attributes to the links, and display and analyze the overall system of objects and links. Rapid Project Spec is a system that assists you, guides you, allows you to quickly go from imperfect knowledge to a preliminary plan.

Please re-read Conundrum #1 above. I was part of the team that was tasked to spec that multi-dimensional problem. We were good, and we were dedicated, and we produced a good needs assessment and a good preliminary plan. But what we realized was that we were relegated to trying to model a complex, multi-dimensional problem with a set of flat, two-dimensional tools, i.e. Word tables, Excel spreadsheets, Visio drawings, MS Project timelines, etc. Those are all paper-based, flat, conventional, two-dimensional tools, and no matter what kind of innovative ways we tried to interrelate them, they were not adequate to perform the multi-dimensional analysis we needed.

Thus I was set along a process of trying to articulate what is the nature of the problem and to devise what would be an effective solution.

When you go into a situation as a consultant, you do not have to be omniscient to nevertheless quickly amass a lot of real, verifiable, and useful information. The clerks, specialists, and managers on the client site do know their jobs and how their business runs. So the consultant can quickly amass a great deal of information about their activities, about priorities, about deliverables and dates to which they are committed. One can catalog the data layers in use and its flow between functions. One can rank activities by percent likelihood, by potential revenue, by chance of failure, by return on investment, and by other useful measures.

Now, obviously, information gathered so quickly cannot be complete. And all that is left in between - what is unknown to you - is so vast that holes seem to gape large enough for the proverbial truck to drive through. Should that circumstance keep you from acting? Should it freeze you in place? No, business realities won't let you - remember that the clock is now ticking, and you are committed to delivering a preliminary budget, schedule, and resource plan in a matter of days to both yours and the client's executive management.

Conventional top-down or bottom-up design assumes that, with time and research, you will be able to fill in these gaps and present a complete scope of the project. And then from that point, there exist tools, tables, spreadsheets, charts, trees, etc. for labeling tasks, relating them, scheduling them, etc. HA!! The market compresses the time to the minimum, the complexity of interrelations quickly exceeds these tools' ability to convey them, and the frenetic pace of changes in technology surrounding the project defeat such a design almost before it is completed. Once again - should that immobilize us? No, no, friend (once again - remember, if I thought there was reason to be immobilized, there would be no reason for this white paper), that should just inspire us to look for some different tools to augment the process.

Notice that I did not just then say anything to the effect of replacing old tools with a new set of tools. That's an important point to keep in mind throughout. Tables, spreadsheets, charts, and diagrams are how business does business. And we want this information which we amass with new tools to be used by the decision makers and business leaders. Moreover, we want it to be integrated into the operations of the business, and to serve the functions of monitoring, managing, and planning the business.

No, what's needed here is the ability to quickly capture, interrelate, and covey all that we do know. We need to be able to encapsulate lists and weights and measures of likelihood, etc. as data objects; we need to label them with terms that are commonly used by the client business; we need to attach attributes to the data objects is some free form manner as they occur to us; and we need to make the connections between objects that are evident at the time. In fact, the connections themselves must be considered objects, also with attributes.

Now I realize that we haven't yet generated the preliminary plan promised above. However, at the risk of delivering more of the best punch lines early in this discussion·

·I think that ProjSpec serves not only the preliminary spec'ing of the project, but it also provides the way to run the project, and the way to run multiple phases which may overlap, and the way to run multiple projects concurrently, and the way to expand and manage the business of running all those projects.

To do that, ProjSpec must be a tool <a set of tools><a process><a consistent approach> which can be applied during each project phase: 1) Needs Assessment, 2) Specification, 3) Prototyping, 4) Implementation, and 5) Review & Redesign.

At the end of this document is an appendix which details how ProjSpec impacts each of these phases. For now, let's just abbreviate into a catchy slogan for each phase:

1. Needs Assessment - "best guess with the information available at the time"
2. Specification - "more complete information"
3. Prototyping - "validate assumptions and build framework"
4. Implementation - "progress reporting"
5. Review & Redesign - "project revision, enhancement, and expansion"

ProjSpec plays and pays at the Project level, at the Management level, and at the Executive level.

At the Project level, the developers face an absolute jumble of minutia, all of which must be taken into account, interrelated, rationalized, and programmed. If one does not encapsulate all this information and functionality into objects and use them to create components, then the development is doomed to remain haphazard and amateur. Professional programmers have long since adopted the object model to organize and manage this complexity, and there are toolsets and an industry sector focused on programming modeling.

A perceptive reader might say at this point, "Why then can't we just use those software modeling tools for the ProjSpec concept?" The answer is that the output of those products is software code and reports about software code. The output from ProjSpec must also be management information and executive information.

Management level must be able to count on two things: 1) that this modeling of the jumble into object components will result in productivity improvements and 2) they must see that the productivity improvements make it possible to manage orders of magnitude increases in complexity and in speed of change.

The Executive level must see that the implementation of ProjSpec will translate into increased profits and present the opportunity for conquering markets - not just compete, but conquer and dominate market segments.

For the object modeling component level, ProjSpec should have 3-dimensional display capability. The viewer needs to be able to view the relative size, shape, and position of objects and the nature of the links between objects. Size, shape, and position are reflections of selected object attributes, such as - measures of complexity, percent completion, resource requirements by the object, cost, etc.

Recall that I've repeatedly called this a multi-dimensional problem. However, since humans see and think in three dimensions, the ProjSpec display must let the user select different viewpoints from which to view the project. This is analogous to digital terrain display software which allows the user to pick a geographic viewpoint and an azimuth and then shows what is visible from there. It also allows for a walk-through or fly-through over the terrain - in this case, through the model.

At the Development level, the details of the components and their object attributes serve both to direct the activities of the development team and then to re-absorb the results of the development activity. Thus the "spec", which was captured in the object early on, specifies for the developers what needs to be done. Then when development on this object has been performed, the actual shape of the object (which invariably evolves and changes from the original spec) redefines the object. The object notifies the rest of the system of its status and its capabilities and availability for use elsewhere in the system.

Although Management level is purportedly also human, ProjSpec output to them is two-dimensional, not three. The language of business is budgets and tallies and schedules, and the media for those are spreadsheets and tables and calendars. So ProjSpec must be completely grounded in the office environment and talk fluently in the language of the office tools. In the current business computing environment, you may just as well capitalize Office (as in MS Office), and you must make sure that ProjSpec writes Word reports, Excel spreadsheets, Visio drawings, and Project timelines, because those are the formats that management can process, refine, and incorporate into their own activities and reports. And it can't just be import and export from Office like almost all products try to do, because those filters are invariably lame, time consuming, and proliferate copies of files and information. No - ProjSpec objects must report themselves for processing in native format by the tools themselves. How else would we expect ProjSpec to become useful in every office in every industry?

So as described so far, ProjSpec can expand out to the detail and minutia that allows the developers to do their job (3-D & multiple-D) and also compresses down to summaries and reports for management (2-D) to do its job. To the Executive level, ProjSpec delivers even more succinct summaries, i.e. lists of bullet items (1-D), because that is all the face time your project is going to get to compete for attention and get the green light from people assailed with requests and without the time to wade through the clutter of project details.

Somewhere between the 2-D and 1-D, ProjSpec will have delivered the preliminary plan promised early in this paper. And as soon as the green light is received, ProjSpec immediately turns back around and instructs the operational teams with how to proceed on management's directive and the spec team's information.

The project has been launched. The spec team is out specifying a new project. Implementation of this project is underway. Is the name "ProjSpec" now a misnomer for all the functions I envision it continues to serve in managing, completing, delivering, and billing the project?

Implementers learn as they develop. A system that allows them to evolve the design of the project is essential, otherwise the design calcifies at the point where management approval was granted. What is learned by the developers is encapsulated in the objects, and knowledge about the availability of completed objects and components must be fed to all the functions of the business. This information is needed by the project spec teams to use on subsequent jobs, by Sales to use to cost proposals, and by staff to be able to respond to RFPs. The results from multiple projects define a baseline of information about how this business performs, and with that comes the ability to estimate dollar values which are no longer out-of-thin-air guesses.

For ProjSpec to produce this stream of development information, it has to be embraced by all developers across numerous projects. This may be the point at which cynics say, "Oh, those ornery, independent-minded developers, they'll resist and defeat all attempts at enforcing a model on them." On the contrary, good developers embrace a ProjSpec-like system, because it works like they work. It allows them to proceed with development on things that they are proficient in doing, and it allows them to come back and fill in gaps as more is learned. It allows you to capture innovative thoughts at the moment they occur to you, and later it categorizes these things as they take on attributes and shape, and it becomes apparent to which class they belong. Since the object model of ProjSpec allows for inheritance of attributes for like objects and for derivative objects, developers don't have to revisit and reinvent. A sufficient accumulation of development efficiencies produces orders of magnitude in increased productivity, which translates to the business as competitive advantage. I know of no professional developer who doesn't wish to participate in precisely that favorable position.

Most small company development environments involve a few key developers who embody all the knowledge of how their system was put together and how it works. Demands on the key developers are constant and always increasing. To expect them to get everything working and to also document the system is not always very realistic. They don't have the time to retrace their steps and enter information about what has been done. A ProjSpec-like system captures what they are doing as they do it, and its reports become automated means for producing documentation and responding to other administrative requests. ProjSpec has an intuitive, self-reinforcing role, and as such is a good friend to the developers, embraced because it unburdens them from administrative duties.

When the business succeeds, those few key developers invariably become key support resources. They know everything, and if no system has been put into place to capture that information, then they are by necessity invariably drafted into assisting user-support. Ironically, for what probably is viewed by other parts of the business as a simple request for support, that very act of responding to it takes the best developers away from and diminishes their ability to develop.

From the administrative, management, and executive viewpoint, one of the simplest of requests to developers is for periodic status reports. They may be surprised to know that for the developers it is a particularly onerous and unproductive task, because it disrupts their development process, asking them to re-create what has already been accomplished and which they have already moved past. One can either talk about programming, or you can actually program. When the development is at its most creative and most productive is not the time to interrupt for weekly or monthly reports. With the self-documenting and self-reporting nature of ProjSpec objects, they know when they are created and when they are done and who is working on them and what shape they are in and what their capabilities are and where they will interface and so on and so forth. When ProjSpec extracts this information directly for the administrative, management, and executive groups, they get timely, unvarnished status, while leaving their best developers unburdened.

In my experience with small companies, they are notorious for working for future considerations and failing to realize current revenues. Quite bluntly, they too often leave money on the table. Work may have been performed, but Accounting is still waiting for a developer to remember to notify them that it is ok to invoice. Better that project milestones be self-reporting - the system in effect notifying Accounting as soon as any milestone has been completed, thus triggering timely invoicing.

Remember that costly team we put together early in this paper? The one you can't afford to dispatch? With Web-based long distance collaboration and mentoring, they can now be available to all of the spec efforts. So now multiple teams can be dispatched, all with access to the experts. In the field, those teams can expect ProjSpec objects themselves to answer many questions, plus they always know that the senior experts are available for augmenting their capabilities. In a similar vein, these objects become the heart of the company's support capabilities, and via web-based collaboration, the support function can also access the senior talents when it is especially needed and appropriate.

Dustin Hoffman in The Graduate is told, "Plastics" - key to the future. The key to ProjSpec may well be "XML".

When we left the project in Indonesia in October of 1997, the concept of ProjSpec was fairly clear to us, and we understood that it needed to be built on an object model. However, I was troubled by knowing that OO databases would never become mainstream in business and offices, where ProjSpec ultimately has to reside. I also didn't have a good answer for my colleagues' questions about how the so-called junior teams would be able to access ProjSpec software.

In the intervening couple of years, the Web has answered these two questions. XML provides the means to encapsulate data and quickly label it using terms attuned to the client's own business terms. XML-specified data can then be processed and presented in different ways by different office applications. And now, the new generation of database servers understands XML and can input and output data in Web-ready XML format.

Another Web advancement which is favorable for ProjSpec has been the advent of Application Servers. This is the means by which a team in the field can access the corporate database, how multiple projects can call on and contribute to the same database, and how teams in any time zone can have 24/7 availability to these capabilities.

ProjSpec teams can now perform around the world, with access to the application server back at the corporate Web farm. Less experienced terms can be dispatched because they know they have a framework within which to collect information, a system of objects they can mine for the components they recognize are needed by their client's projects, and access to the experts and support they need to confidently master the complexity of the situation they face.

ProjSpec addresses the conundrum of rapid project specification. It turns out that definition #2 was the correct one - the complexity we face does present us with challenging problems, but they are neither impossible (definition #1) nor is it a joke (#3). ProjSpec is the tool for specifying jobs, for implementing projects, and for expanding the number of projects that can be managed simultaneously. ProjSpec is for developers and managers, for admin and executive. ProjSpec is doable.

Copyright. 2000. Joseph G. Jay. All rights reserved.