CMMI stands for Capability Maturity Model Integration.  The purpose of CMMI is to identify, document, and evaluate processes in our organization and ensure that these processes allow us to effectively meet our business goals and that we have a methodology for continued process improvement.  According to SEI, CMMI can be used as a framework for appraising the maturity of an organization’s business and work-related processes.  The appraisal (called a SCAMPI – which stands for Standard CMMI Appraisal Methodology for Process Improvement) focused on one of our projects for the Federal Government. 

The link to our appraisal results published by SEI is:

https://sas.cmmiinstitute.com/pars/pars_detail.aspx?a=20407

The CMMI process has assisted Information Concepts in more effectively meeting our major corporate goals including:

• Development of a uniformly positive customer experience on all of Information Concepts’ software development projects.
• Continuation of our industry leading success rate of over 95% of our software projects going into production.
•  Ensuring that our methodologies for project delivery are well documented and repeatable.
• Providing a methodology to insert customer and project team feedback to improve future project delivery.

To support CMMI, Information Concepts developed written procedures for project delivery, trained our staff in these procedures, and performed quality reviews on our projects to make sure our procedures were implemented.  We originally went through the CMMI Level II certification process in 2010 because it was a requirement for us to hold certain Federal Government contracts. We have found the CMMI process valuable in a number of other ways.  It pushed us down the path of documenting our methodologies and practices, enhancing our methodology to follow these processes, and verify that the processes have been followed.  

We expect to undergo recertification again in 2016.

Albert Einstein once said,  If I can’t see it, I can’t understand it. This is the basis for utilizing visualization tools in the requirements gathering phase of software development projects.

Most projects that fail are due to miscommunication between the business stakeholders and the development team. Visualization tools combat this, allowing you to quickly see your software solution before a single line of code is written. Advanced visualization tools enable extremely rapid prototyping with online publishing and critiquing that can cut the time and cost of requirements gathering in half.

Visualization tools make traditional requirements sessions appear heavy and arduous. The resulting simulation is so rich in functionality that you can actually show your stakeholders what they are going to get. In fact, the prototype is so robust that it can be used for training purposes while the development effort is underway.

This seminar is designed to discuss tools that engage stakeholders and get the requirements right, the first time, before development begins.

We envisioned creating each of the reports using the SSRS web service and then writing some kind of console application to create emails, find recipients and then include the right reports as attachments. The code would need to schedule creation and delivery, as well as complete descriptive email subject captions. We found a better way. Microsoft Server Data Driven Subscriptions.

Microsoft Server Data Driven Subscriptions is paid-for system code that will create and email reports on a schedule that you define. The configuration is through SSRS menu screens. These screens include functionality for recipients, cc, the subject line of the email and have very rich scheduling options. Once your stored procedure is written, you use these screens to map the output parameters of your  stored procedures to the input parameters of the SSRS report. The stored procedure also provides email addresses.

You do need to create a shared data source to point at your database and you need to write your stored procedures. As a rough sketch, our stored procedure for the territories report returned a row for each territory that included the territory database id, the time period for the report, the subject line of the email (including territory name and datestamp) and the recipients for that territory. We had no trouble getting multiple emails to work – we had the stored procedure create them  as:

‘Joe@verizon.net; jane@comcast.net;fred@arrl.net’;

When we exceeded 10 reports per stored procedure, we had to increase the number of reports that SSRS allowed one user to have active at one time. This was accomplished through changing the MaxActiveReqForOneUser line in rsreportserver.config.

We are quite happy to have Microsoft system code do our heavy lifting for us and perhaps this is something you can benefit from as well.

John Heartney (1 Posts)

John received his BS in Computer Science from Iowa State University. He has worked at IBM, Kastle systems and Coop Systems before coming to Information Concepts.

My thought was to break out the individual sections the user would navigate into separate user controls. To avoid a massive page load, these user controls would be loaded in as needed via a jQuery AJAX request already populated from their code behind file.

The first step in doing this is to create an ASHX handler to load the user control. Since ASCX controls are not made to render on their own outside of a page, this handler would have to render the control within a page and then return the html.

Thus, the html within the page just consists of the user control requested with the parameter “control” is returned.  The next step is to make the jQuery AJAX request to call UserControlHandler.

As you can see, the user control requested is TargetUserControl.ascx. You can also add any data the user control might need in the ajax data element, then just pass it to LoadUserControl after it has been stripped out of context.Request.

The next step was handling submission of form elements in of the user controls. If you take a look at the HTML code rendered in the page at this point, you’ll see that the user controls are wrapped in an empty form tag.

Since this page is supposed to operate like a portal with no page refreshes, we’ll also submit the form contents with ajax serializing the contents of the form tag.

Then within PageName.aspx you define a webmethod to handle the saving of the data.

The DataParser object is a custom string parser I defined for the project. The method that’s important here is ParseSubmitString which basically splits the serialized string on ‘&’ so that you have a result of key=value strings which can then be parsed.

Shawn Skelton (1 Posts)

Shawn is a Technical Consultant at Information Concepts with a Bachelors Degree in Computer Science from Eastern Washington University.

In my 30-plus years at Information Concepts, I have managed or overseen the management of well over 100 software development projects of all sizes, so I have seen the pitfalls here.  I put together this post to better explain how we should be managing development projects, and why.

When we start a development project, we ask the Project Manager on our Business team to create a Development Worksheet.  A Development Worksheet is simply a spreadsheet containing a list of all development tasks required to complete the project, organized logically by system component (Web Pages, Business Functions, Web Services, etc. organized by Subsystem).  We do this in a spreadsheet instead of a project plan (which we use for planning purposes) because it reduces the noise typically contained on a project plan, eliminates any distractions, and provides a very clear picture of the actual project status.

As the project moves forward, the Lead Analyst will update the status of each task with the person performing the task, the date it was started, its status, and its eventual completion date.  We only recognize 3 valid statuses:

• Not Started.
• Started.
• Complete.

At Information Concepts, we do not use percentage completion at the development task level.

Why not?  Very simply because there is no way to accurately project the percent of completion for a development task prior to its actual completion.  Additionally, percentage completion provides a misleading indicator of progress.  I have seen many projects with multiple tasks marked as 80% or 90% complete, however, these tasks cannot be finished because of an issue blocking their completion — which might require a change to requirements or a development prerequisite that cannot be completed and will, therefore, need to be redefined.  More often than not, this gets overlooked because of the 90% completion indicator.

Instead, when we create development tasks, we need to make sure they are easy to understand, manage, and track.  Tasks are at a very granular level.  Rules for defining tasks are as follows:

• A Task should be comprised of one (and only one) logical unit of work (i.e. a Page or Screen, a complex Grid or Table, a Report, a business function, etc.).
• Make sure that each Task can be independently tested.  Ideally, it should be possible to test a Task stand-alone (although this may not always be possible).
• Keep tasks small and short.  A task should be no more than 2-3 days in length. This allows fast identification of any problem tasks.  If a Task is longer than a few days, divide it into multiple subtasks.

A Task is not complete until it has been thoroughly tested.  Complete means complete!  It does not mean almost complete, or 90% complete, or complete if one last item is finished in some other place in the development process.

The only time it is acceptable to use a percentage completion methodology is for a large Task (i.e. subsystems or major application components) with multiple smaller tasks or subtasks.   For example, in a subsystem with 5 screens, if 2 of these 5 screens have been completed, the high level task can be considered 40% complete.  Although this is misleading since the size of any given subtask can be radically different, it is necessary for project reporting purposes.

If we use the methodology described above, it will greatly simplify identification of problems during development – which is the actual goal of project tracking!

Cary Toor (2 Posts)

Cary Toor is a Co-Founder and Principal of Information Concepts, Inc. Since the company’s founding in 1982, he has personally managed or overseen the management of numerous large and small software development projects for Information Concepts’ customers, as well as provided software architecture support for complex projects. In this role, he developed Information Concepts Project Management Strategy, including processes and techniques, which have allowed Information Concepts to have an unparalleled success rate in delivery of software development projects to its customers.

“When all of the stakeholders come together so quickly, you’ve got magic” – this is what happened a few minutes after the Superdome went dark during the 2013 Super Bowl. Oreo’s Ad agency, working closely with the business, developed an ad and sent it out to twitter, resulting in an instantly successful marketing coup.

 As business teams work with the technical groups on Software development efforts, success is based on the same requirement, stakeholder engagement.

The keys to stakeholder engagement are time (short), and attention (captivated). Visualization tools allow stakeholders to see results in hours, not weeks. They stay involved because they can test-drive their designs and changes prior to any code being written.

David Schulman (2 Posts)

David Schulman is the principal of Information Concepts’ Visualization Practice. David oversees the implementation of Information Concepts’ unique rapid-prototyping abilities, allowing for the creation of simulation of software that look and act like the real thing, all before a single line of code is written. Prior to joining Information Concepts, David founded CloudOPX, a Google Apps Reseller and Migration company. Mr. Schulman has over 30 years of experience in information technology and holds a Bachelor of Arts degree in Economics and Sociology from Hampshire College.

Without skipping a beat he replied – “That’s the Two-P Syndrome”*.

“The Two-P Syndrome? What’s that?”

“Poor-Planning”

I laughed. But then I realized that he was spot on. I could argue that my lack of knowledge makes it impossible to plan. Or, I could use the response I routinely receive from every contractor I’ve ever hired… “I don’t know what it’ll cost until I get into it.”

I thought about IT projects and realized that the same rule applies. The difference is, that with software development projects, you really don’t know what it will cost until you get into it. No amount of up-front planning can accurately estimate the cost of the total project. Why? Because the users defining the requirements don’t know what they want until they can see it, experience it, and test it to see if it even solves the problem.

In this blog series we’re going to explore the problems that contribute to the absurdly high failure rates of IT Development projects and what you can do about it.

*It was actually the “Three-P Syndrome”, but I have cleaned it up for a wider audience [Ed.]

-          David Schulman, Principal, Visualization Practice

David Schulman (2 Posts)

David Schulman is the principal of Information Concepts’ Visualization Practice. David oversees the implementation of Information Concepts’ unique rapid-prototyping abilities, allowing for the creation of simulation of software that look and act like the real thing, all before a single line of code is written. Prior to joining Information Concepts, David founded CloudOPX, a Google Apps Reseller and Migration company. Mr. Schulman has over 30 years of experience in information technology and holds a Bachelor of Arts degree in Economics and Sociology from Hampshire College.