Inexperienced and/or over-eager technology workers often unintentionally increase the risk of software project failures due to three common mistakes:
Lack of transparency
One of the biggest challenge with each of these classic mistakes is they often go unnoticed, potentially even rewarded or encouraged by project leaders and project managers … until it is too late and the damage is done. But why and how does this happen so often in our industry?
Lack of transparency. This comes down to one thing. Communication. In over 25 years of experience, I have observed that this is often a skill that many software developers simply have to work on as it does not come naturally. Most software engineers are logical, introspective thinkers and very much focused on getting right to work problem solving. Generally, people of action and few words. The problem is, software developers often have a tendency to jump right in and start “doing” without sharing or vetting their ideas, or taking the time to research all viable options before starting to change code. Communication, and full transparency are critical for cost-effective design selection and productive development phases.
Over engineering. This is a personal pet peeve of mine because I have been burned so many times by this mistake, both as a developer and project manager! WAY TOO MUCH time can be spent on creating an elegant, clever, over-engineered solution, especially when a simple direct approach is available, can be a huge time waster … and is often very costly!
As problem solvers, we enjoy technical challenges and like to avoid having to revisit code by (over) engineering a solution trying to anticipate when end users will change their mind … um I mean requirements. But in doing so, we may fail to realize or consider the unnecessary cost and effort involved. Don’t fix what aint broke, yet!
Often, complex solutions that may be considered by the creator to be “brilliant” and “ultimately flexible” can be poorly documented and extremely difficult to understand or maintain. Worse still, after hours of attempting to make these over engineered solutions work, the effort can prove fruitless and abandoned as unfeasible. Use the KISS principle …
Shiny objects. In a word, distractions. In a software project, this typically manifests itself in scope creep. This, however, is scope creep that originates from within the development team … “hey, let’s do this too while we are in here”, or “wouldn’t this be cool?” These suggestions can often be encouraged and accepted by the Project Lead or Manager as a client “bonus” … as it comes from an enthusiatic developer team member who swears they can do it without affecting the delivery timeline. The PM may also accept these to get buy-in from the developer and to avoid discouraging this type of proactive behaviour for team building. However, these types of side-tracks, often combined with lack of transparency, can be a project killer. Stay on track, stay focused, don’t get tempted by shiny objects.
Change impact analysis tools by FinditEZ provide a full 360 degree view of your entire code stack. Produce more accurate estimates, identify the right resource skillsets required, quickly run “what if” change impact cost scenarios to confidently select the most cost effective option. Transparent, easily distributed change lists for clear and simple communication. Perfectly engineered solutions. Change made simple @ https://www.finditez.com
For a medium to large enterprise that has grown through mergers and acquisitions or simply through years of success, just knowing what custom software source code assets you have can actually be a daunting challenge. However, having this knowledge can lead to better decision making and tremendous cost savings.
Take this first example from a recent customer inquiry. “We know that we need to upgrade some of our middleware and underlying database version due to advances in technology. We need to migrate to for security compliance, lower support costs and to benefit from improved performance. But we don’t even know how many Crystal and SSRS reports we have! We estimate there is over 5000 reports and we would like to extract and move any embedded SQL statements within them into the new target database as either a view, function or procedure. Where do we start?”
Perhaps not surprisingly, this is a very common challenge for a large organization relying on a complex, multi-language and multi-tier software applications to run their business. The software itself is big part of what distinguishes them from their competitors. It is a mission critical proprietary asset that needs it’s inventory ( content ) to be documented, current and relevant. This in turn facilitates efficient and cost effective ongoing enhancements and upgrades to the underlying operating system or middleware as needed from time to time.
IT staff and skills come and go. When some of the senior staff move on, you often lose valuable knowledge and understanding of complex system inter-connections. You need a way to have new staff find those relationships with current and up-to-date documentation to maximize their productivity and minimize introduction of programming errors.
FinditEZ supports technology across the entire analytics stack.
# 1 – … and the number one factor affecting the probability of project success or failure is, by far, the accuracy of the estimates themselves. It really does come down to that. Budget for the project is allocated based on the ( resource time and cost ) estimates. Target completion and milestone dates are based on the ( task effort ) estimates. Design and cost/benefit decisions for what’s in, what’s out and the best way to accomplish the in-scope deliverables are based on the estimates. You need to get this right, everything else depends on it.
Despite advances in software estimating techniques and software engineering in general, the art of producing accurate estimates remains elusive. Without a good estimate, it is virtually impossible to deliver medium to large software enhancement projects on time on budget and as specified. After years in the industry, and trying everything from function point analysis to lines-of-code complexity metrics, I came to the conclusion that biggest challenge was the accuracy and source of the information used to base the estimates themselves on. Let me explain.
First and foremost, you need to get a clear understanding of in-scope deliverables. Next, you need to recruit a team of subject matter experts to gather intelligence for the estimating process. At the early stage, it can be difficult to get the attention of key programmers and systems analysts within an organization. These same resources are typically frantically finishing off or recovering from implementation of the last big project they were on before being allocated to your new project team. What to do? You need timely, accurate and complete information about the scope and complexity of software changes you plan to make.
From my personal experience, using ballpark estimating tools and techniques like function point analysis gets you in the ball park at best. You have no formal list of actual affected items to support your seemingly outrageous estimates when sitting in a room with the stakeholders and they say “come on, you can do it faster or for less than that … it’s just a couple of tweaks here and there”. In fairness, how can you argue with that? Without an objective list of “here’s exactly why and what’s affected” to support your proposal, you only have your educated guess, reputation and charm as back up. Ever been in that situation? Wouldn’t it have been nice to have just such a list … instead of bending to the pressure and adjusting your estimates down to an unrealistic and unattainable doomed target? It’s a story too often experienced and told.
Even with good estimates, it is critical that the project itself be properly managed. Stay focused, on task, in scope. Communicate. Don’t be afraid to ask for help when needed, raise the red flag when you run into unforeseen circumstances that you recognize may affect your ability to complete tasks as estimated.
The old saying is true, garbage-in, garbage-out. You have to get the estimates right. Stop using ballpark Wild Ass Guess tools and techniques, and look for products and tools that can create accurate checklists of exactly what would be affected throughout your entire application if you change software component or database table “x” to deliver feature “y” in the requirements specification. When you have accurate and complete change lists, you are empowered to:
determine the precise scope and complexity of each task
identify the ideal resource skill-set requirements for each task
produce estimates that will reflect the actual effort to complete changes with the highest possible degree of certainty
justify and defend your estimates with objective facts
# 2 – The second most important factor that has a direct impact on the first, is truly understanding and clearly documenting the project requirements. In order to ensure you deliver what is needed, you have to get this right … and make ABSOLUTELY sure you get it in writing!
Spending the time to document and collect as much information as possible at the project initiation stage will actually save time and money in the long run. It will allow you to categorize a list of “must haves” vs “nice to haves” based on cost/benefit. Focus your effort on what your client wants, not what you think they need or would like. You will virtually guarantee end-user buy in and ownership by encouraging them to really think about and communicate a clear and concise project scope. Getting it down on paper with their signature is a must.
A picture paints a thousand words. By far, what I have found to be the most effective and efficient way to communicate and document requirements is through the use of concrete samples and mock ups created by the end-users themselves. This includes reports and screens. By requesting samples of exactly what they are looking for, you can often derive the root needs and system design changes that will be necessary to produce accurate estimates based on a clearly defined set of mutually understood, in-scope deliverables.