The Art of Finding Facts

The Art of Finding Facts

The exciting aspect in fact finding is simply that there are so many different ways to search out and identify facts within a business domain. If we find that one technique doesn’t seem to be delivering what is expected, we have 5+ additional techniques we can employ in sequence or in parallel and in various combinations until we feel we have identified a sufficient fact population to accomplish our goal. Kendall, K.E. 2011 singles out and defines the following fact finding techniques, all of which should be considered by an analyst at the beginning of each systems design project as potential ways of identifying critical facts related to the new system:

Brief Overview – Fact Finding Techniques

  • Interviewing – face-to-face conversation with those who have a relationship with the system
  • Joint Application Design – approximately a week long design workshop involving a mix of user, IT, and management all working together to develop business requirements for the system
  • Questionnaires – paper forms, electronic formats (email, webforms), remote or in person used to obtain facts from a user’s perspective
  • Investigation – using existing non-human data sources relating to the system
    • Quantitative Document Reviews
      • Decision Making Reports
      • Performance Reports
      • Records
      • Data Capture Forms
    • Qualitative Document Reviews
      • Memos
      • Signs/Posters/Bulletin Boards
      • Corporate Sites
      • Manuals
      • Policy Handbooks
  • Observing Behavior (decision maker) – watching and recording how the decision maker(s) performs their job functions in order to identify how this might affect the design of the system
  • Observing Environment (decision maker) – reviewing the environment in which the decision maker(s) perform their job functions. Our environments give off subtle clues as to our personalities and our personalities affect the way we use systems


In the majority of cases throughout my professional life, when faced with fact finding in relation to a complex system, I have never employed just a single fact finding technique. I usually find that I instinctively use at least 2 different techniques in order to make sure that all my bases are covered. This also provides, in my opinion, the highest probability in locating the majority of the critical facts which apply to the systems I am developing/designing.

I have also noticed that the 2 different techniques I might use may not always be the same combination as I used on the previous systems design. This is due to the fact that with each new system, the environment in which I am working has changed. The changes can be as slight as a different department within the same company or as substantial as a different company altogether.

For the majority of the systems I have designed I have employed some combination of techniques from the top four items in the list above: interviewing, joint application development, questionnaires, or interviews.

Here are some of the environmental factors which usually affect the combination of techniques I employ.

Time

I have found that the majority of all enterprise systems I have worked on or designed there is always a time crunch, a crunch which was there before the project was ever conceptualized. This ever present lack of time dramatically affects an analyst’s ability to perform proper fact finding. When time is the issue, I usually find myself turning to the techniques which require the least amount of time to complete. This is whether or not they are considered the best or the worst for the task at hand.

Technique Selection: questionnaires, maybe a few interviews if I can find the time

Freedom

I have found that some management styles preclude analysts from free access to the users and those invested in the system. With restricted access to those important sources of facts, analysts are left to less interactive techniques which at times can be more time consuming and less constructive.

Technique Selection: Investigation

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
  Pearson Education, Inc., publishing as Prentice Hall

The Birth of a Use Case Description

The Birth of a Use Case Description

A use case describes a specific transaction that happens within a system and are most likely initiated by an actor (an entity that is external to the system). Each use case describes only what the system does not how the system does it (Kendall, K.E. 2011). This means that the description of a use case focuses on the perspective of a user outside the system interacting with the system. It should be worded in plain English, is nontechnical, and should be understood by just about anyone.

In order to make sure all use case descriptions fit the definition above a specific set of steps should be instituted in regards to their construction. By following a specific set of steps in the creation of use case descriptions it is more likely that a team will be able to create more accurate and informative descriptions. It will also make the descriptions generated more uniform across the board (developers, projects, company).

Step 1: Interview to Identify Tasks

As with all development we are trying to provide our customers with a piece of software which, based on our best interpretation of the customer’s needs, provides a solution to the problems or opportunities that lie in their path.

The primary way to provide our customer’s with an accurate interpretation is to actually listen to them when they are telling us what they need. This can best be accomplished via one on one interaction while recording their needs.

It is through these interviews that we can begin to identify and recording the individual tasks which are involved in completing the system transaction which the use case describes.

Step 2: Ponder & Ask Questions

Once the tasks have been captured some time needs to be taken to actually review them. By analyzing the tasks we can often find incongruent or missing tasks which need to be clarified or added by the customer.

All questions which arise from the review should be presented to the customer for clarification, explanation, or validation. This should be done in person to increase effectiveness.

Step 3: Identify All Inputs and Outputs

Although the tasks may be clear prior to this step the inputs and outputs involved in those tasks may not be. In this day and age where information (data + context) is extremely valuable and ever present almost every transaction a system processes either consumes or produces information, often times both.

It is vital that customer’s are queried in regards to each task in the transaction in an attempt to identify all inputs and outputs so they can be properly identified in the description. Failure to do so can have severe consequences in development.

Step 4: Look for Patterns

It is not uncommon for multiple transactions within a system to share repetitive tasks or for specific tasks to repeat within a transaction. These repetitive tasks can often be identified via iteration or looping patterns. It is important that these patterns be identified in the description in order to avoid duplication of effort when in development.

Step 5: Verification

The final use case description should be verified by the customer. Since all descriptions should be both readable and understandable by anyone the customer should be able to read through the description and immediately provide feedback as to whether or not the transaction and its associated tasks described within the use case actually fits their understanding of the transaction in reality.

Step 6: Sign Off

Some may argue this step is a bit too much but if you have ever dealt with fickle customers who always seem to forget that they agreed or approved something this step can be a lifesaver in the long run.

Although all customers forget, there are different degrees and different types of forgetfulness. The ones I am pinpointing here are those that have suddenly had a change of heart or want or suddenly realize that what they thought they wanted isn’t really what they wanted and decide that they should forget that they approved a user story for development. Normally this would be fine but when everyone has agreed upon a sprint backlog and a delivery date this forgetfulness can cause some real trouble for the developers, analysts, and project managers.

To mitigate this I prefer that the client, after verifying the user story, sign and date each user story in blood (ok not blood, ink will do). This not only makes things official but forces the customer to really think about the user story before signing. This hesitation is due to the fact that people value their name and are rarely ok with placing their name on garbage.

Conclusion

A little extra effort upfront saves factors of effort at the end.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
  Pearson Education, Inc., publishing as Prentice Hall

101 Uses for Prototypes in IT Projects

101 Uses for Prototypes in IT Projects


It may just be that I have had a unique experience in my development career or that I have just been lucky in regards to the companies I have worked for, but when I am asked the question “What kinds of IT projects specifically lend themselves to the use of prototyping?”, my answer is every single one I can think of.

Let me explain why this is my answer. In the book we are lead to believe, at least this my interpretation, that prototyping is only used when we need to show something to the customer in order to get feedback on requirements, confusing or not (Kendall, K.E. 2011). But in reality prototyping is used by developers in so many more ways than just show and tell.

Yes we use it to clarify and verify that what we intend to build meets the customer’s expectations as referred to in the text. But we also use prototyping in the following ways which make it extremely valuable in pretty much any IT project I can think of.

Effectiveness of a New Technology

Technology moves at such a breakneck pace that pretty much every time I have begun a new project, we have been forced to reevaluate the technologies we used in the last project against the latest and greatest just released technologies by powerhouses like Microsoft.

In order to evaluate these technologies to see if they will be a correct fit for the new project, prototyping is always involved. Being that technology selection has, in my experience, been the duty of the Software Architect she usually spends a bit of time at the beginning of the design phase prototyping out key features of the system, utilizing the new technologies in order to prove them as viable replacements.

An example of this was when I was the architect on a large redesign of an existing archaic system. The plan was to replace the system, keep its functionality intact as is, but update to the latest and greatest technologies for the sake of future proofing the system and increasing maintainability. The archaic system was developed in .Net 1.1 using old ASP.net web forms. The current version was .Net 3.5 and Microsoft had just released their version of an MVC framework. Before we simply dove right in and took off with Microsoft’s MVC we prototyped some of the current system’s key functions in MVC and proved that it was a superior technology and a suitable replacement platform.

System Integrations

Even if we are sticking to technologies we are already familiar with when it comes to system integrations, there is always a proof of concept done in order to prove that the integration is not only possible but that the technologies used on either side and as connectors have what it takes to get the job done.

I had experience with this when I integrated a health profiling platform, which we had created, into an employee health benefit platform. Our system was built on .Net 3.5 ASP.net and their platform was built on a Java web framework. The integration was to be done utilizing what is called SAML (Security Assertion Markup Language).

Despite the fact that our technologies were proven and both ends of the integration had experience with all the technologies involved, a prototype of the integration was created in order to prove the integration concept and architecture before expensive resources, effort, and time were dumped into a full blown development initiative.

Conclusion
I left out a few other examples for the sake of brevity but from those I presented I hope it is clear that although prototyping systems for the sake of requirements clarification and verification of UIs can be extremely effective in obtaining a customer’s true requirements, they can also be extremely useful behind the scenes. It is due to this behind the scenes use of prototyping that its use is not limited to only specific types of IT projects, but to any and all types.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
   Pearson Education, Inc., publishing as Prentice Hall

Determining Project Scope in Systems Design

Determining Scope

To begin let’s define what scope means as defined by the Project Management Institute:

Project Scope “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.” (Project Management Institute, )

Scope is one of the most important items to be defined in a project. It also needs to be one of the first. This is because without a proper knowledge of the scope of a project it is extremely hard to figure out and estimate all the details of the project. Without a proper scope it is impossible to identify and limit all the tasks involved in the development process. It also becomes impossible to estimate the overall cost of the project as a whole.

Scope Creep “refers to uncontrolled changes or continuous growth in a project’s scope.” (Scope Creep, n.d.)

Scope creep is one of the most painful points in systems development and for those who have been involved in the development process you have experienced just how painful it can be.

In order to avoid scope creep and create a project schedule that is as accurate as possible, scope has be identified, limited, and agreed upon by the major parties involved. The only way to effectively accomplish this is to develop and instantiate some form of process through which all projects can be moved when dealing with scope.

The Process

In my experience dealing with Project Managers, Scope, and Project Champions keeping scope under control requires a detailed process as well as acceptance of that process by all involved prior to the project kickoff. If everyone is made aware of and accepts the process and its procedures for dealing with scope, there is a higher chance of success when it comes to controlling scope and its tendency to creep as projects mature. This leads me to the first part of my process:

Procedure 1: Identifying Power Players

Before scope can be decided upon or controlled we need to have a clear picture of who has what power within the project and what that power allows them to do and dictate. With a well defined power hierarchy identified it will be much easier to know when and where you can say no and who you need to go to in order to have no communicated.

  • The Power Payor: the ones ultimately paying for the new system
  • The Power Management: the ones who are neither paying nor using the new system
  • The Power Domain Expert: the one who knows all in regards to the business domain and/or the existing systems being replaced
  • The Power Users: the ones who will actually be using the new system


Procedure 2: Identifying Business Domain(s)

It is extremely important that we understand the business domain(s) in which the information system will be built. Depending on the business domain(s), scope may be more difficult to determine and external experts may be required in order to accurately determine the scope of the system.

Procedure 3: Reviewing Existing System(s)

If there are existing systems which are to be replaced by the new system those systems can sometimes be a really good resource when it comes to determining the existing scope of the system. This will allow you to focus your attention to new scope that may be introduced due to the needs or changes in business which have inspired the development of the new system

Procedure 4: Interviewing Primary Users

It is important when determining scope that the primary users are located and interviewed in order to identify the requirements which they see as the most important or critical in their work. Ultimately it is the users of the system who we are building the system for, with the goal of improving their efficiency, effectiveness, and speed in their everyday work.

Procedure 5:  Identifying Business Value

A thorough review of all requirements within scope should take place and business value should be identified and tied to each. By tying business value to each requirement we can potentially identify requirements in the scope which are superfluous or were inserted into the scope based on personal bias/desire.

Conclusion

No matter which procedure we are working through there is a good chance there will be discrepancies discovered, requirements that seem out of scope or superfluous, or requirements which smell of personal bias/desire. When we run into such cases we will need to figure out whether they are within scope or not and the best way to do this is to identify the power player who best fits the current phase and discuss the issues with them. These discussions may end up in negotiations so it is always a good idea to brush up on your negotiation skills.

In cases where a specific power player cannot be identified, it may be acceptable to gather a list of issues and obtain feedback from the entire power player group to come to a consensus on each issue.

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
    Pearson Education, Inc., publishing as Prentice Hall

2. Project Management Institute. (2008). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition.

3. Scope Creep, (n.d.). In Wikipedia’s online encyclopedia
   Retrieved from http://en.wikipedia.org/wiki/Scope_creep

The Factors Involved in Accurate Project Work Estimations

Factors of Accurate Estimation

In reality I am not sure we can actually identify all of the factors involved in estimation let alone accurate estimation. That being the case I will focus on the major factors which create the most variance in our estimations based on my experience as a Software Architect.

1. Experience of the Project Manager – Nothing beats experience when it comes to estimating the time it will take to complete a particular task within systems development. The more experience a PM has had in the field of systems development the more likely they will be able to properly gauge whether or not an estimation provided to them is actually within a reasonable range. The only way to know the range, is to have dealt with estimating similar tasks in the past. Although the PM is not necessarily the one giving the estimations, it is her responsibility to know when the wool is being pulled over her eyes, she is the guardian of the project.

2. Experience of the “Expert” – The reason for the quotation marks around expert is due to the fact that not every development department will have the same level of experience in its “experts”. I have been involved in start up companies which did not have the budget to hire experienced developers or architects and therefore they rely on junior developers as their experts. I have also worked in companies with what seemed like unlimited resources and had numerous amazing and experienced developers on which they could rely for estimations.

It is obvious the more experience an individual has designing or developing systems the more they know what kind of effort, knowledge, and resources are required to complete specific tasks. With that knowledge comes the ability to better estimate how long it will take to complete those individual tasks.

3. Estimation and work disparities. What is meant by this, is when the estimation for a task is given by an expert but the work is assigned to a junior developer or someone less familiar with the work. This disparity can cause huge problems in keeping estimations honest and schedules true.

4. Resources Available – No matter how experienced your team is, no matter how fast they can complete the work needed, a PM must always take into account whether or not those resources are available to work on the task they are estimating. Lack of resources can delay tasks as there may be the need to wait for team members to complete other work before they are available to complete additional tasks. This may place a project in a holding pattern and tasks will not be completed on the projected schedule based on the estimations created.

Two-Point Estimation with Weighted Average

As pointed out in our text, the two-point estimation method with a weighted average is a task estimation process in which the project planner utilizes both an optimistic and a pessimistic estimate, usually provided by an expert.  Then by utilizing a weighted average formula, calculate what is supposed to be a fairly accurate final estimation for the task (Kendall, K.E. 2011).

Throughout the years this has been the most common method for task estimation I have run into. In fact, no matter what the actual Systems Development Methodology was we were using, we used this method of estimation about 99% of the time.

Delphi Method

The other 1% of the time I have utilized what is called the Delphi Method. In this method a panel of experts is constructed with each expert answering a series of questions regarding the task being estimated. Once each of the experts has answered, subsequent rounds are completed allowing each expert to revise their estimation of the task based on the input and additional comments of the other experts (Delphi Method, n.d.).

It is thought that through this process of iterative refinement and after a determined number of rounds, the expert’s estimations will gradually narrow until they are almost identical. As the expert’s estimations narrow, it is thought that they are gradually approaching the most accurate estimation possible (Delphi Method, n.d.).

Three-Point Estimation

Similar to the two-point estimation, the three-point estimation takes in a best-case, likely-case, and worst-case estimate from an expert and then utilizes those values to create an approximation probability distribution. This probability distribution is then used in an attempt to predict the possible outcome (Three-Point Estimation, n.d.).

Conclusion

I have only touched on a few of the many factors which affect our ability to accurately estimate our tasks. It is our ability to effectively estimate the work needed to build information systems which will give us a more accurate total cost of development.

Knowing that there are many factors which affect estimations, it is always a good idea to understand the major methods of estimation which attempt to give one the most accurate estimations possible.
 

Sources/References

1. Kendall, K.E. (2011). Systems Analysis and Design.
     Pearson Education, Inc., publishing as Prentice Hall

2. Wysocki, R.K. (2009) Effective Project Management: traditional, agile, extreme. 5th ed.     
     Indianapolis: Wiley Publishing.

3. Delphi Method, (n.d.). In Wikipedia’s online encyclopedia
    Retrieved from http://en.wikipedia.org/wiki/Delphi_method

4. Three-Point Estimation, (n.d.). In Wikipedia’s online encyclopedia
    Retrieved from http://en.wikipedia.org/wiki/Three-point_estimation

Advantages & Disadvantages of the SDLC

A Little Disambiguation

The acronym ‘SDLC’ is used within the technology field for more than just one ‘thing’ and those ‘things’ are so closely related we enter what seems to be a recursive loop in defining one or the other.

  1. Systems Development Life Cycle
  2. Software Development Life Cycle


I come from a software development background as a Web Application Architect for a healthcare technology provider. When I initially read the first chapter of ‘Systems Analysis and Design’ I was completely confused in that what they were describing as ‘Systems Development Life Cycle’ was in fact the good old ‘Software Development Life Cycle’ I have been using in one form or another over the past 7 years they had just given it a different name.

After a little research online I found the reason they are so familiar, ‘Software Development Life Cycle’ is thought to be a subset of ‘Systems Development Life Cycle’. This is due to the fact that it focuses not on the complete system but instead on a specific piece of software or a product which may only be a component of the complete system (“Software Development Process”, n.d.).

Assumptions

Another concern I ran into in the reading is that the book treats the SDLC as an actual step by step methodology for system design and implementation whereas in my experience it has been considered to be the overarching ‘theory’ as to the cycles involved in a systems life not necessarily how they should be designed. With the SDLC being the theory of the life of an application there have been various methodologies spawned from it in order to actually do the design and implementation.

From my understanding and experience the following design and implementation methodologies were created in direct response to handle the SDLC (Systems Development Life Cycle, n.d.):

  • Waterfall
  • Spiral
  • Agile
  • Rapid Prototyping
  • Incremental
  • Synchronize and Stabilize


Please feel free to help me out on this one if my understanding is imperfect or skewed based on my perspective. I have just never run into a development effort where someone said we were going to use the SDLC this time, they have always utilized one of the methodologies listed above.

Since the book is treating the SDLC not as a theory but as an actual methodology I am assuming our discussion is focused on the strict SDLC process as outlined in the book (Kendall,2011). It is from this standpoint I will address the following points.

Advantages

Strictly speaking, the reality of all system design efforts is the fact that no methodology is ever perfectly executed as prescribed. But if we were to step into a perfect world and were to execute the SDLC in its entirety we would obtain the following benefits:

Complete Documentation of the Entire System

The SDLC dictates that there be painstaking attention to detail in documenting not only the overall design of the system but all pieces thereof,including but not limited to: existing systems, business needs, business processes, software, databases, interfaces, user manuals, training material, etc (Kendall, K.E. 2011).

Complete System Design prior to Development

The entire system including all of its pieces are designed prior to the start of development. A benefit of this is you have a much better understanding of the overall system, how each piece fits into the whole, and the responsibilities each piece has within the system. It removes a lot of the uncertainty and doubt once development begins.

Disadvantages

Slow Rate of Change to Meet Business Needs

Due to the extremely detailed and step by step processes within the SDLC it is extremely rigid and inflexible. Businesses today are constantly changing in order to pull ahead of the pack and gain competitive advantage. A lot of this change is due to just how fast paced technology is developing and its direct impact on said businesses. Mixing a rigid design process with an extremely dynamic business can only lead to the inability for a system to change at a rate fast enough to keep up with the business needs.

Lack of, or Monopolization of Resources

Because the enormous amount of effort required to design, document and then develop an entire information system and all of its required features at once using the SDLC it requires an equally enormous amount of talent. This leads to either a lack of resources or a monopolization of existing resources. In either case it will end up costing the business in additional salaries or the inability to hit other business directives due to lack of resources.

Suitability

Based on the identified factors above the systems which would benefit the most from a strict adherence to the SDLC would be large to extremely large information systems which are relatively stable. In other words complicated, possibly distributed, systems which live within industries which have a relative low rate of change in their business process. Examples would be industries like: Healthcare, Finance, and Government.

The converse also holds, the SDLC would not be a viable option for medium to small information systems which live within industries which have a relatively high level of fluctuation in both business processes and accelerated advancements in the technology used to gain competitive advantage.

Conclusion

No matter the methodology you end up selecting it will have its advantages and its disadvantages. It is up to you to weigh them all and select the one whose advantages outweigh the disadvantages or whose advantages best fit the business needs creating greater competitive edge.

Sources/References

Kendall, K.E. (2011). Systems Analysis and Design.
      Pearson Education, Inc., publishing as Prentice Hall

Software Development Process, (n.d.). In Wikipedia’s online encyclopedia
     Retrieved from http://en.wikipedia.org/wiki/Software_development_process

Systems Development Life Cycle, (n.d.). In Wikipedia’s online encyclopedia
     Retrieved from http://en.wikipedia.org/wiki/Systems_development_life-cycle