Understand Project Pricing

Project Management Cost Summary

Project management includes only the costs of our project management services, and is priced separately from production costs. To clients, project management is usually the most visible key to a successful project. At Prospus we strive to apply established project management best practices, and to that end we have adopted a uniform framework promoting consistency and better control of projects, thereby reducing risks and increasing project successes.

Despite the application of best practices, in our experience we have discovered that there is no one-size-fits-all solution for managing software projects. Some clients are content to exchange 1-2 emails and receive a single weekly status report from our project managers. Other clients require higher levels of interaction extending to continuous email dialogues, live chats, and even face-to-face interactions. With each of our project managers overseeing multiple projects, it is essential that we understand the level of interaction our client’s demand so that we can properly commit our resources.

It is common in IT for project managers to become overwhelmed by project demands, leading to lack of availability, delayed responses, and a general sense of neglect. At Prospus we have innovated a unique concept of allocating project management resources on a subscription basis. This allows our clients to specify exactly what they expect from us communication-wise, ensuring we can meet those needs internally by adjusting the workloads on our managers. The result is more satisfied clients who know exactly what to expect from Prospus and how to connect with us.

Subscription Service Chart

Despite sharing some core project management principles, projects vary to a great degree. Since every project is unique we have found it effective to offer our clients options for their project management needs. To this end we offer four subscription plans for project management services, with each plan offering a successively higher level of access to our project managers throughout the duration of a project. Each of our subscription solutions come bundled with a particular set of entitlements, however our clients are free to upgrade their project management subscription to suit their requirements.

Prospus System Estimate Methodology

Any development estimate is based on a combination of known requirements and assumptions. At Prospus we have a proven method for deriving requirements and enumerating assumptions that permits us to accurately estimate the costs of building complex systems . Before we can arrive at a realistic project estimate we use our proprietary methodology to determine the number of elements within the system and the approximate complexity. Starting with the client requirements, from those we elicit additional technical requirements by conducting various analyses. Assuming the requirements are fully known to us, we can commit to a relatively narrow budget range and timeline.

Client Requirements

Client requirements are the foundation of any project because they contain the description of the desired functionality from the client’s perspective. We solicit client requirements in all formats and contexts and use them as the basis for our formal technical analysis. The quality and detail of the requirements documents provided by the client will directly impact the timeline and success of the project. Incomplete requirements will lead to longer timelines and, possibly, misunderstood project goals.

The Pitfalls of Software Estimation

It is nearly impossible for contractors to provide a reliable project estimate without first knowing all the requirements. And yet clients rarely know all project requirements unless they have had a professional technical analysis performed. Since most clients do not do this, contractors who do bid are often doing so without knowing what they are bidding on! This leads to all kinds of problems. Take a look at this project posted on a popular online marketplace in late 2016:

Looking for a skilled programmer to complete the back end of a website that will be running time value of money and cash flow calculations to assist people in planning for retirement. Expertise in mathematical equations and programming required. Website will be interactive, using data from an existing API to pre-populate certain input fields and will be responsive to user inputs as well. Results page (result of the retirement calculations) will be interactive, allowing the user to adjust variables and see new outcomes. Project is urgent – deadline to complete is less than 30 days away, so please contact us immediately!

Just what exactly does this client want? The contractor who was awarded the project initially bid $3,000 on the project, but after two months realized that the scope was far greater than he had anticipated and resigned from the project. The client ended up spending $2,500 for an incomplete web-based application, and the contractor lost a valuable opportunity to deliver a great product. Why did this happen? Two reasons: 1) the client described a complicated system with one paragraph, and; 2) the contractor didn’t have a proper estimating procedure in place to assess the project before bidding on it. Had the client detailed every function in their system, or had the contractor inquired more thoroughly about the functionality requirements before taking the project, this might have been avoided.

Prospus ended up picking up this project and completing it for six times the original bid, absorbing some of the client’s original losses, but gaining a valuable and loyal client in the end. Since there won’t always be a Prospus to swoop in and rescue a failed project, as a client how can you avoid scenarios like this? We have three tips:

• Be aware that the primary reason software projects fail is that full requirements were not known or understood in the beginning, resulting in unexpected development costs and delays.
• Be willing to invest some time and money in describing exactly what you want before you post your job. If possible, hire an analyst to map out your project so contractors know what they are expected to build. This is virtually mandatory for dynamic projects with multiple interacting components, or those exceeding $5,000 in value. Prospus has expert analysts ready to help you map out your system requirements.
• After posting your job, thoroughly review the bids you receive which interest you. Do your homework and ask contractors how they are estimating development costs. At Prospus we strongly suggest you do not work with contractors who cannot justify their development estimates. Such estimates are often based on competition alone, and have no basis in the actual requirements of the project!

Remember, if you choose a contractor who doesn’t understand the requirements, you will be the one facing the loss when the contractor realizes it’s more work than they thought! This happens every single day, especially on online contractor marketplaces

The System Requirements Analysis

The easiest way to ensure project success is to know your project requirements ahead of time and to hire a contractor that fully understands them before starting the project. Non-engineers usually capture system requirements as lists, documents, or even in user stories. It is the job of the professional systems analyst to convert these “client requirements” into “technical specifications”. The process for producing a full set of system requirements will vary with the project; some methods are great for certain types of systems, but poor for others. While you may not understand everything your contractor produces under the banner of “system requirements”, it is imperative you critically review them if only to ensure that they convey a plan and a deep understanding of your system.
Prospus offers a comprehensive Systems Requirements Analysis service for clients seeking only to formalize their project technical requirements. For more information please request the latest version of our informative document “Prospus – System Requirements Analysis”.

How It Works

There are great risks in bid-based software development, especially in online marketplaces where clients have grown accustomed to posting incomplete requirements and receiving competitive bids despite it. At Prospus we have used our expertise in the field of software development and project management to create a highly-reliable software project estimation methodology. Over time we have enhanced our method, and it has proven itself time and again to be thorough, accurate, and reliable. The remainder of this document describes in detail every aspect of your Prospus project estimate.

Our estimation methodology is based on a simple premise: size by complexity by labor rates equals development costs. To approximate the size of a system we break it down into its most basic components, called “elements”, and then estimate the time to build each element using historical data we have collected from past projects. The next step is to estimate the complexity of the project, which we do by categorizing the functional requirements of each element. Together, these two metrics form a “system profile”. With this in place, we can apply our standard labor rates to arrive at a robust, historically-validated solution estimate.

By breaking down a system into sections, Prospus can produce well-rounded, highly-reliable and accurate estimates of the true costs of a software system. This leads to fewer surprises and better results for client and contractor alike. We pride ourselves on our 100% transparency and ability to justify our pricing, and we always make the logic of our estimates available to our clients. We are willing to review and revise our estimates if we have overlooked something, and we always welcome our clients and prospective clients to question our assumptions.

The remainder of this section details our estimation methodology and is supplementary to a Prospus development proposal. Note that we are always updating our methods to account for lessons learned and industrial practices.

Understanding Your Estimate from Prospus: Elements

The accuracy of our estimate depends on our ability to project, in large part, the number of unique elements in a system. There are six types of elements we consider when evaluating a project: subsystems, actors, use cases, pages, tables, and classes. With a reasonable approximation of the elements in a system, we are confident that we can accurately project the system’s development costs to within 10% of its actual final cost.

• Unique Subsystems. Every software system is comprised of one or more subsystems which perform some specific set of tasks within the greater system. At Prospus our disciplined analysts are trained to break down every system into its respective components so that we can better understand how each part will function. Often there are open source or proprietary subsystems readily available in the marketplace. Other times we will need to develop the subsystem from the ground up. Either way, decomposing the system into subsystems is essential to producing modular, high-quality software that is easy to use, maintain, and enhance.
• Unique Actors. Every system has users who do something with that system. In engineering we frequently refer to these users as “actors”. Every actor has a role and a specific set of activities, constraints, and relationships within the system. Before preparing any estimate, our analysts identify all unique actors within the system.
• Unique Use Cases. When an actor performs some action, it is called a “use case”. For example, an administrator actor might be able to block a user account, or moderate a comment. Use cases are the best way for a systems analyst to outline everything the users of a system need to do. Identifying use cases is one of the fundamental elements of the Prospus Estimation Methodology. Note: A single use case often translates nicely into a single page or function, but other times it may require multiple pages or functions to be achieved.
• Unique Pages. Pages are the fundamental element of the user interface for a system and are the primary method for interacting with a system. We consider a unique page to be a single interface for any given application, website, or app. Pages can be made to gather input (e.g., a login form), produce output (e.g., a report), or some combination of the two. All dialog boxes, popups, and full pages are considered a page. We only count pages one time. For example, if we create a page that displays a single product and then dynamically program it to display every other product in an inventory in the same way, we only count it one time. We also do not count pages which are included by default in a free or paid-for system, such as an administrative page in an open source content management system. Note: On a website an interface is usually called a “page”, whereas in an application they are generally referred to as a “screen”. We simply call them “pages”.
• Unique Forms. Most dynamic websites rely on forms for collecting information from users. Forms contain elements such as text fields, input boxes, check boxes, radio buttons, date selectors, and other common controls. The data collected on forms is usually transferred to the database, which requires both programming and database administration. By estimating the total number of unique forms in a system we can gain great insights into the pages, programming requirements, and database structure.
• Unique Tables. Modern websites and applications rely on databases for storing and retrieving the content and data needed to operate. Databases are divided into tables which contain the data for a specific entity within the system. For example, one common table for a website is the “user” table which contains the login username and password for every individual registered on the site. We count all unique tables which we must design and build ourselves; however, we do not count tables which are part of existing third-party software.
• Unique Classes. The glue which binds together pages and tables is the programming code contained in the application files. There are various ways to program an application, but well-formed programs are always broken down into logical subdivisions. These subdivisions are what we count as elements. In some cases, a subdivision is known as a module, other times a function or class. We do not count classes which are part of an existing third-party solution or code.

Complexity

Size alone is not reliable enough to substantiate an accurate system development estimate. If it were, a 10-page blog about cats would be costlier to build than the single-page Google search engine. The greater costs behind a system are incurred with functional complexity. While evaluating the complexity of a system is difficult and time-consuming, it is vitally important, and therefore we give a great deal of attention to it before we bid on a sizable project.

Prospus has devised a proprietary leveling system for ranking the complexity of a system, from 1 to 5. The simplest systems are Level 1, template or static-based applications. They require a minimum amount of user input and configuration and are usually greatly limited in their flexibility. On the other end of the spectrum are bespoke applications which are built from the ground-up for a specific purpose. In assigning a complexity level we consider each of the subsystems within the system and assign a complexity level to each of them separately. The aggregate score determines the entire complexity level of the system, or individual component within the system. Combined with the number of elements, we can accurately forecast the complexity of producing a system or system component, which can then be used to identify the most suitable labor resource for the work.

• Complexity Level. It should be obvious that some systems are more complicated than others, and therefore require greater effort to produce. At Prospus we have analyzed thousands of data points across our own projects to define and categorize project complexity. The result was a reliable 5-point system for quantifying the complexity of a system based on the following metrics: model, platform, customization and activity. These four metrics together accurately determine the complexity level of the website.
• Complexity Modifier. The complexity modifier represents the incremental costs required to build a system of a specific complexity in relation to the base level (Complexity Level 1). For example, a system with a Complexity Level 4 is costlier to build than a system of Complexity Level 2, and therefore incurs additional expense in its development. The complexity modifier captures this additional cost and serves as the basis for all additional calculations within the system estimate.
• Model. Broadly speaking, there are three general types of systems, depending on the functions it performs. Usually a system is clearly one or the other, and only rarely will one model suffice in place of another. At Prospus we recognize the following system models:
  • Static. Often referred to as informational, or “brochure ware” in the case of a website, this is the most straightforward type of system. Such systems merely contain information in plain text, with supporting images and content. The uncomplicated nature of such systems means they are relatively easy to build and maintain. That said the effort required to maintain and enhance static systems grows exponentially with size.
  • Dynamic. On a dynamic system, content is stored in a database and published according to the requirements of the system users. Such systems are frequently used by businesses that publish large volumes of information in a standard way (e.g. news organizations). However (within the terms of the definition used here), it should be noted that a dynamic system does not necessarily allow transactions (i.e., there may not be an ability to “log on” or to “buy”). Although the user experience of a dynamic system is like that of a static site, the technology that underlies it is much more involved
  • Transactional. A transactional system is the most complex model because it supports multiple simultaneous users collaborating within a single or across multiple workspaces. The variety of technology used in transactional solutions (application servers, security systems, etc.) means that a team of highly qualified staff is needed for support.
• Customization. Every system is built for a purpose. Often that purpose has already been addressed by other systems meeting the same needs. The customization metric of a system has three broad categories depending on the level of unique requirements:
  • Template. A template system is one that is built exactly like another system. They are easy to build and often require little more than installation and answering a few questions. Template systems are usually the cheapest type of system to build.
  • Bespoke. The opposite of a template system is a bespoke system, which requires full customization and therefore requires the need to be built from the ground up. Bespoke systems are almost always the most expensive type of system to build.
  • Hybrid. Hybrid systems combine both elements of template systems and bespoke systems, and their price range is usually between the two.
• Activity. System activity is one of the most important factors for planning and developing a system. Busy web-based systems inevitably must deal with mountains of feedback, customer problems, and general issues of upkeep. As a result, activity levels have a great impact on the way a system is developed and maintained. The activity level of a system is determined by the anticipated number of page impressions it will receive in a month. We recognize three general levels of activity:
  • Quiet. Systems which do not expect a level of traffic greater than 50,000 impressions per month can be considered quite small, and do not require any additional reinforcements.
  • Intermediate. Systems with more than 50,000 impressions and fewer than 1,000,000 impressions per month should be moderately reinforced, adding some complexity to developmental considerations.
  • Busy. Systems receiving more than 1,000,000 impressions per month should receive the full range of scaling and reinforcement enhancements, adding considerably to the complexity level and costs of development.

Element Discovery Costs

Every element within a system needs to be identified, analyzed, and prepared for development. During the discovery stage our analysts and user interface experts analyze the system requirements and identify all the necessary elements (pages, tables, and classes). The objective during the discovery phase is to create a plan for development. A successful discovery phase results in greater organization, more efficient development, better-structured systems, and lower overall costs.

• Requirements.
  • The requirements phase of a project is the process wherein all the project features and functions are defined. Usually clients provide simple documents or lists describing what they want their system to do. These documents are not appropriate for development and therefore an expert analyst needs to elicit the requirements from the client in a form which is suitable for an engineering team. This process involves interviews, discussions, and dialogues aimed at clarifying specific functional requirements.
  • Standards Used: UML
• Technical Analysis.
  • Once the requirements have been gathered, our team of business and systems analysts take the next step and translate the requirements into formal specifications and tasks appropriate for development. System specifications are basically requirements, but written in high-level technical language for engineers and analysts. This is one of the most complicated processes, requiring time, concentration, and expertise.
  • Standards Used: UML, BPMN
• Documentation.
  • All systems built by Prospus are thoroughly documented for both ease of use and future maintenance. We follow a “document as you go” approach which translates into the greatest level of knowledge preservation and lowest ongoing maintenance costs.

Fixed Costs

Every system incurs certain fixed costs, regardless of size or complexity. Fixed costs generally increase for larger projects, but at a slower rate than other development-related costs. The exact costs in this category vary between project types and so will not be detailed here.

Variable Page Costs

Every page built for a system, whether application or website, has costs which go into its construction. Everything from prototyping the page through to designing, developing, and eventually deploying it are captured in this set of metrics. Variable page costs usually constitute the largest part of development costs, and our estimates are based on data from hundreds of projects we have worked on.

• Modeling.
  • Before any page is built, our user interface analysts build an online, simulated model. This is launched on our development server and gives clients an easy way to click through their system and provide feedback about the interface. Only after the client has approved and signed off on the model do we proceed to build it. Although this service adds time and expense to the process initially, ultimately it acts as a quality control measure, saves costs, and streamlines the development process.
  • Technologies Used: XHTML, HTML5, JavaScript, Adobe Photoshop, Adobe Fireworks
• Design.
  • After a page is fully conceptualized and approved by the client our talented web and graphics designers design the graphical interface. Prospus designs are guaranteed to be unique, authentic and modern.
  • Technologies Used: Adobe Photoshop, Adobe Illustrator, Adobe Flash
• Styling.
  • Once a design is approved for application, our expert web stylists slice the images, embed them in HTML, and apply the CSS. Prior to styling, our designs are simply static images, but after styling they are vibrant, dynamic pages capable of working in concert with a variety of programming languages.
  • Technologies Used: XHTML, HTML, CSS, Eclipse
• Front-End Development.
  • Front-end development is handled by a variety of experts, depending on the requirements of the project. Front-end developers are valued because they are both designers and developers; they understand logical languages like JavaScript, but also understand and apply the principles of graphical design in the user interface. If there is a third-party API to integrate, front-end developers will often handle it. Our front-end development experts work to make sure that pages are cross-browser, cross-platform, and cross-devise compatible. They also ensure that usability is maximized, pages meet accessibility requirements, and performance is optimized.
  • Technologies Used: JavaScript, HTML, Third-party APIs
• Back-End Development.
  • Back-end development is the work spent building the database and connecting it to the various pages using programming languages like PHP, ASP.NET, and Java. Our code is fully-documented and our professional programmers and database administrators follow internationally-accepted software engineering standards for MVC, modular, and object-oriented development.
  • Technologies Used: UML, PHP, ASP.NET, Java, Python, MySQL, SQL Server, WordPress, Joomla, Drupal
• Testing.
  • After all modeling, designing, front-end and back-end development, pages are ready for testing. Our software testing experts conduct a full barrage of user, browser, stress, device, and platform tests to ensure a system is functional, secure, bug free, browser compatible, and friendly.
  • Technologies Used: Selenium
• Training.
  • Once the site is developed, tested, and delivered we prepare and deliver full training for the customized pages of the system. All training is conducted to ensure that clients are fully comfortable managing the system with a minimum level of assistance.

Programming Costs

Much of the engine that fuels a system is often performed behind the scenes in lines of programming code and database tables. A system’s data is stored in a database, which is then accessed by lines of code written by programmers. These programming costs are captured by approximating the number of custom database tables and custom classes we will need to build to create the system. In determining programming costs, we consider both database and coding figures.

• Database. The database layer is the foundation of a system and can be estimated by approximating the number of tables that will need to be created to run and maintain the system. Prospus maintains a highly-qualified staff of educated and experienced database administrators to build and maintain databases.
• Code. The code, or logic layer, generally connects the user interface to the database. All logical functions and entities within a system are built within the code. Prospus has an agile and versatile team of programmers with a wide range of experience in numerous languages, platforms, frameworks, development environments, and CMSs.