Blogs

Leave this line for spacing

Leave this line for spacing

Blogs

“An official wants to multiply subordinates, not rivals.  Officials make work for each other.” – Cyril Northcote Perilinson

Consulting – 28 June 2021 – The Iceni Team

According to the Oxford Dictionary, a consultant is “A person who provides expert advice professionally.”  The keywords in this definition are “expert” and “professionally.”  Therefore, consulting should never be confused with sales but as sage advice on a given problem.  Either they represent a company with a solution or just as a consultant, sound advice, not sales, should be the priority.  

So, what creates a great consultant instead of a good consultant?  A firm understanding of the client’s needs and desires leaps into mind.  This understanding describes why most consultants tend to be well experienced in their field with years of experience.  But how would you develop a great consultant?  Various training programs are a start, but only as a start. After that, one-on-one mentorship is the key.

These mentorships get the seasoned professional to observe and assist the newer consultants towards a better path for success.  Point them in directions of study, in both technical and people skills to better understand their clients and their needs.  Again, not a sales job, a professional advice role.  Every option for the client should be explored; some clients need a single solution; others have in-house resources that just need to know the options available.  Then there is the budget problem; consultants should do a cost-to-benefit analysis for the client.  This goes with the previous statement and expands it.  For example, if the problem is solved with the in-house resources to handle it, they might just need refinement of requirements.  If not, and they are looking for an off-the-shelf solution, then solution options should be provided.

Demanding customers are many and varied, and a great consultant will know how to deal with them.  It is especially with demanding customers that mentorship is paramount.  The previous blog talks about Alternative WorkSpaces (AWS, i.e., remote) and the importance of keeping the personal connection.  So, besides some group programs for the basics, the one-on-one relationship and evaluation are crucial.  

Recent studies have shown that remote work is not only the path forward, as it allows a much larger pool of candidates, but there does still need to be some social interaction as well.  Perhaps a video chat room where anyone within the organization can access and just do the water cooler thing to a weekly “happy hour” for non-work chat and just getting to know each other.  The water cooler and happy hours help the team to mesh, share ideas, complaints, successes, and lessons learned.  In addition, a group meeting for awards and recognition is an excellent idea to boost morale and expand everyone’s talent pool.  We are all on the same team, so we should perform that way. If a problem arises and you already know who has successfully solved it, you know who to go to.  There is always, of course, the old greybeard manager that should be kept in the loop so they know what they are doing right and where they can improve as well.

Alternative Work Space – 21 June 2021 – The Iceni Team 

 With the pandemic almost behind us, at least some hope, at any rate, many companies, and even Federal, State, and Local governments are moving towards Alternative Work Spaces (AWS).  Not to be confused with Amazon’s cloud services.  This movement has had several impacts.  More

For starters, workers like working from home and/or remote offices as the commute is far more manageable. Managers, especially old-school, are worried that they cannot keep track of their workers as easily.  So let us examine the pros and cons of the new norm.

The pros are that there is no longer the need for large real estate rent purchase or upkeep for the workers. Also, the freedom to hire from anywhere has opened up.  If your ideal worker lives in another place, no problem.  It does make life work balance much easier, cuts down on sick days, and research has shown higher productivity.

The cons are providing secure networks, which is much easier to do in a single location, lack of interaction between workers, and the possibility that new ideas are not discovered by accident standing around the break room, or an idea hitting someone that could then directly run it up the chain.

So how do you get around these problems?  First, we will talk about security, essential, especially now with ransomware attacks as well as general phishing.  The best plan is to have a dedicated machine for work on a VPN to make security work.  The hardware should only be used for work, and should some malware or other threats appear, just disconnect and report.  It is also important to not erase anything that was captured, as that makes further investigation problematic.  Instead, report the suspicion to the company security and as necessary to the authorities.  In the recent ransomware attack on a major East Coast pipeline, the FBI did recover most of the money.  Also, standard security checks should be applied on a consistent basis.

Next, virtual break rooms are a good idea when colleagues can discuss new ideas or even just random thoughts.  And another good idea is to have a weekly “happy hour” where everyone gathers with a beverage or snack of their choice and talks about non-work subjects.  These meetings bring the team together in a social setting, no matter where they are.  Until it gets to be a habit, pose an opening question, such as what was your most embarrassing moment at work, something no one else knows, or other questions.  Keep it semi-professional, no intimate details or anything that could be construed as a hostile work environment; the idea is to have friendly chats to learn about each other and build team cohesion.  You always want to know that if things go south, there is a group that has your back.

As the world becomes more routine, a mix of virtual and in-person meetings will become the norm, so planned gatherings are good ideas.  For example, in The Iceni Group, most are in the Dallas area, which is likely to change, but we have an East Coast person, likely a West Coast, and someone in the mountains.  No reason not to have an off-site in any location for interpersonal connections.  These would, of course, be funded by the company and brings us all closer together.

Project Leaders – 31 May 2021 – The Iceni Team

Long ago, and still, in some cases, the Project Manager was in charge of their team and knew what the system or product being delivered was all about and very often served as the Chief Systems Engineer. But, unfortunately, it seems that trend is fading into Project Managers becoming glorified accountants, just planning and tracking schedules and budgets, with little actual knowledge of what the system does and why it is being built in the first place.  More

We at The Iceni Group would like to see that change from Project Management to Project Leadership; the difference is that besides keeping the books – Project Leaders would be the interface to Stakeholders, take care of their team, and understand why a problem is being solved. Instead of excuses for why they are behind schedule or over budget, their approach typically throws some on the team “under the bus.”  Project Leaders will see the upcoming risks and adjust to minimize those and buffer the team from harm.  Never forget that success is due to a Team. Failure rests only on the Leader.

In making a Project Leader, one needs to focus on the problem, understand the history, understand the solution, and most of all are part of the team.  As a Leader, one would be responsible for the big picture technical oversight and caring and managing of your team.  This includes working with all stakeholders, keeping them informed of progress and potential risks, and keeping the relationship open and honest.  The worst thing you can do is surprise the stakeholders; the same goes for the team, never surprise them with new requirements or a change.

In building a good team spirit, one needs to respect their skills and knowledge, as no one can get into all the details, treat them with respect, listen to their ideas and act accordingly.  Further, there is no place for any bias based on race, gender, etc.  Also, encourage them to have fun together at work and off work as appropriate.  Make their work environment as comfortable as possible; open discussion should always be the case.  Ideally, your teammates should feel free if there are personal issues and assured you would not share their individual needs with anyone else unless they wish.  Building trust among the team should be a priority.

So, who makes a good Project Leader? I would recommend a sound engineer, probably systems, but most engineers have the same mindset; one will also need good people skills and love to learn about new things, a polymath.  Also, one who puts the team first, oneself second, and feels good about a job well done.

The First Client – 14 December 2020 – The Iceni Team

It is my pleasure to announce that we had our first client with The Iceni Group.  While we will not mention the client’s name or project, we did learn a lot about how we operate.  Remember the blog on Lesson Learned?  We had quite a few.  On the plus side, we did experience much more of our capabilities and our processes.  More

 

A client asked for a cost estimation, given a brief overview and specifications for pricing purposes to better understand their viability in the US market.  The client is a foreign-owned firm and specializes in an industry about which we knew little.  When they asked if we could come up with some pricing estimates, we naturally said, of course, we can and proceeded to price materials based on the information provided.  However, after looking at the plans, we had questions, and this is when The Iceni Group swung into action.  Some of the supplies were straightforward and easy enough to estimate.  There were, however, some that had us scratching our heads.  This second issue was because there were several different options on the product to buy, how it was going to be used, and so forth.  As written about in several blogs, we then set out to gain more knowledge, as any good engineer would do, the most being the Requirements and CONOPS.  After some initial research, we reached out to various contacts, some we knew, someone we knew someone who knew someone to understand the problem better and make the best estimates we could.  A practice we will always follow for two fundamental reasons.  First, we gather much more information on the history of similar projects and their lessons learned.  Second, we made some useful contacts and built relationships that might lead to more business and expanded or sources of information.  

The first lesson learned was that if you ask, people, in general, are happy to help, especially if it is near and dear to them.  The next was to deliver something as simple as a cost estimate and get it right; it is very beneficial to understand the history of the problem you are setting out to solve.  Unfortunately, the third was that this would add to the turn-around time, but it is the right thing.  The last important thing to understand up-front is defining what the client is looking for and how accurate it needs to be.

Being hungry for a win, we underestimated the time this costing will require.  It was also difficult to ascertain if the client was looking just for cost or searching for a US-based partner?  Was this project an exercise to decide whether or not to pursue business in the US, and as such hypothetical, or was it a project they were pursuing?  These questions kept coming up without definitive answers.  Either way, The Iceni Group prides itself on being as accurate as possible.  In this case, the definition of the client’s stakeholder status was a little vague, so we are pursuing those answers at the time of this writing.  To further add to the complications, time zones and language are also part of the issue.  The client is fluent in English; however, as anyone can tell you, the same answer from an American vs. British vs. Australian, even Canadian, can mean different things.

No matter the outcome, we see this as a win, as our collective abilities came together to help answer the questions.  It also helps to understand better each team member’s strengths and weaknesses and how best to use them in future ventures.

Who We Are – 7 December 2020 – The Iceni Team

The Iceni Group currently has five members, all of which have extensive knowledge in Project and Program Management with various expertise.   More

 Three of our team have served as Program Managers on comprehensive programs from the Program Management side, and the last two, Mike and Carlton, as Deputy Program Managers. We all have Project Management experience as well.  In addition, we have all done our time on the bottom end as software engineers, systems and electrical engineers and mechanical engineers, operators, tech support, trainers, and mentors.  

With both government and commercial experience, we know how to conduct business on both sides.  Full disclosure, most of our careers have been in the DoD and Intelligence communities doing our bit to bring down the Soviets and then search for terrorist activities.  However, It is safe to say we are also polymaths, have a wide range of knowledge, and continue learning with each new project.  We all also have a good deal of experience overseas and have seen different approaches to similar problems and work and play well with people inside and outside the US.  As we neared retirement age, we opted for earlier retirements and then became somewhat bored.  Somewhat frustrated with the heading of our primary industry, as far as programmatic downfalls we were seeing, we decided instead to focus on consulting to restoring some of the good practices we had seen and helping the next generation overcome the burdens of bureaucracy and focus on the job.

Efficient Project Execution – 30 November 2020 – The Iceni Team

Advances in technology as applied to more complex and challenging global problems have resulted in larger Projects to implement Systems solutions.  Smaller, well-defined projects with a coherent technical team and a centralized Project Manager have been replaced with extensive ill-defined Programs with large disconnected teams governed by multiple Managers with differing agendas.  More

 In addition, the project team structure has become a compromised ineffective network dependent on personnel availability, not technical ability. The Program Manager, who in the past was both the Leader of the project team and the Customer interface, has become the coordinator of schedules and status meetings and the deliverer of financial targets by any means possible to meet the business’s goals. This paradigm shift has resulted in programs missing schedule milestones, program scope creep with subsequent increasing costs, and ultimately the delivery of less value per dollar to the Customer. This corrosion of value can be turned around through Project and Technical Leadership, coherent project teams, and more structured execution teams tailored to the project size, goals, and duration.  

In its simplest terms, on a project, the Engineering team executes a series of scheduled milestones within a customer awarded budget to develop and deliver a product in accordance with a set of customer requirements. There is a Chief Engineer or a Project Lead responsible for executing the program that guides a team of Engineers through the project’s duration. Depending on the project’s size and the different Engineering disciplines involved, there may be multiple sub-leads, from Software, Hardware, Systems, and more. A top-down Leadership approach is usually the most effective and efficient if the Leads are experienced, and the workers have technical skills that match the project’s needs. Inefficiency creeps into a program when management assigns their respective representatives to additional leadership roles that do not add value to the project. This altering of the fundamental project structure adds unnecessary cost to the project and often creates conflicts in Project Leadership.

In addition to the project team, a Program Manager (PM) is responsible for the business for financial performance and the Customer for product delivery. The PM has a slew of other functions supporting the program providing financial reporting, contract interpretation, scheduling, quality management, data management, and more. Over the years, the PM has become less technical and distanced from the real work performed to satisfy the Customer. In most large organizations, the PM calls the shots because the financial goals are often more important to the company than the Customer’s technical and operational goals. These restraints can create a situation where the value to the Customer is subservient to profit to the company.

How can we improve the efficiency of programs to deliver the most value to the Customer while still turning a profit to keep the company viable? How can we enhance program performance by eliminating redundancy in leadership and matching organizational structure to the program’s complexities and requirements? Let’s take a look at history to determine what has impacted project management and cite an example of success in turning a project around.

There was a time when the typical Project Manager/Chief Engineer would be responsible for the technical big picture and resource control and presentations.  As time progressed, many companies fell into the Parkinson’s Law trap, which sums to say that management wants subordinates, not rivals, and that management make-work for each other. Parkinson’s Law is best shown during World War II, where before the war, it took two logistics officers per ship to make sure that the ship was fueled, supplied, and tracked.  By the end of the war, this number was up to 150+ per ship.  It is not that the work got more complicated; it was that bureaucracy took over.  What took a single letter now had to be duplicated into other forms signed by several officials and still overseen.  The bureaucracy took over the actual work that needed to be accomplished and did little to improve efficiency.  

The bureaucracy took charge, and gone were the lean teams that got work done.  Thus Project Managers were now the gatekeepers of paperwork and not involved in the solution.  A lean team is by far the best use of resources; just be careful not to make it too lean.  The lean approach is accomplished by diversity within the team so that should something need to be handed off temporarily, it could, and that every member of the team should have insight and the freedom to bring up ideas or concerns.  For this, a Project Leader is needed.  The Project Lead needs a robust first line of sub-leads and knows their people well enough to manage resources and build them as needed.  My own best story is that as the Systems Engineer on a project, I was responsible for making sure that the eight products that had been prototyped by others would fit in a much larger system, be fully integrated and supply the required training and materials for the system owners to maintain our products after sell-off.  The team consisted of myself, two software people, two testers, and a hardware technician.  Since the final sell-off would require documentation and training, we all took on multiple roles.  Software wrote elegant and well-documented code, both in the actual code and in documents.  The testers not only wrote and executed test plans but also wrote operator training manuals and trained the operators.  While the hardware technician made sure everything would physically fit, was well labeled, and prepared the system’s hardware support team.  My go-to guy for covering customer relations when I was unavailable was the lead tester.  Together, our team delivered what was described as the best product the system had ever seen, and we even met all of the bureaucratic requirements of integration.

This project’s overall success was due to a good Project Leader who knew his team their strengths and abilities and led to create the “productization” standard for our particular industry.  This success would lead to a normalization of a prototype to product in record times with minimal bureaucracy across our industry, all while satisfying the bureaucratic requirements.  What used to take years in planning and implementation was now taking months.  The lean team means understanding the rules that must be followed and meeting them in spirit, if not letter, and requires Project Leadership, not just Project Management.  The key to good Project Leadership is the full understanding of the end goal and the team’s relationships.  The Iceni Group not only aids in Project Management but strives to make Project Leaders.

In Summary:

  • Efficient Project Execution consists of Project Leaders that understand the end goal
  • A well-allocated team makes for Efficient Project Execution
    • Team diversity and skill mix provide growth opportunities and multi-tasking options.
  • All team members should be kept in the loop of progress and issues
    • Everyone should understand and have input to requirements and CONOPS
  • Efficient Project Execution must also create a protective barrier between the Customer and the team
    • Don’t let the Customer go direct to their favorite part of the Project and dwindle resources by trying to “help.”
    • Always have a back-up person to aid the Lead, which also helps them grow.
  • Beware the Parkinson’s Law trap, understand the letter of the Law in the bureaucracy, find and sell the most efficient method of meeting the spirit

Development Options – 23 November 2020 – The Iceni Team

First off, no matter what development strategy is chosen, never fall into the “Ready, Fire, Aim” trap as this will end up with a poor result of the final product, or worse yet, never achieve your desired goal. More

 

Waterfall Development

Waterfall development is best when you have dedicated resources and no need for technological breakthroughs.  The best historical example is the Great Pyramid.  It was known where it would go, how it would look, the materials and labor identified, and several previous builds to follow.  Other examples would be pre-computer ships, planes, automobiles, or any other mass production product.  Any new additions would be added to the next class, not during production.  If you cannot resist new technology, it can skew your schedule and cost estimates without ensuring success.

Agile in Incremental Development

Agile or any incremental development is best used when there are gaps in how you plan to finish your product or have variable resources.  Again you must understand what the end goal is and when you can declare success. An excellent example of this is the wagon trains that moved settlers West from one known place to another.  Success was evident when your people and supplies were safely delivered. Although trails were known and could be reasonably well estimated in costs, several factors made it much more unpredictable a journey.  To combat the uncertainty, Wagon Trains had advanced scouts to make sure water, food, and supplies were in place for each part of the trip and could offer alternatives as conditions changed.  Such is the case with software development and integration; just be sure to have reliable configuration control and test plan in case you need to back up again.  

Conclusion

Many projects today misuse “Agile” as a way to never finish; if you look back at any of the incremental or waterfall strategies as initially envisioned, they are all valid based on the circumstances you find yourself in and should be used accordingly.  All of them also emphasize understanding the problem and how to tell it has been solved.  This is not to say that problems will grow and expand over time. Just make sure that the on-going project is well defined, leading to follow-ons that will continue your success.  Always remember the phrase “Ready Aim, and Fire” in that order. 

Project Tracking – 16 November 2020 – The Iceni Team

There are many ways to track the progress of your projects.  Many Project Management Professionals (PMP)s will advocate the Earned Value Management (EVM) approach; however, other methods deliver far better results. More

 

EVM Pitfalls

EVM is a comparison of your actual budget against your predicted budget, all math-based.  A good Work Breakdown Schedule (WBS) and the associated budget estimates can give you an EVM number if applied against a traditional Waterfall development.  This approach is flawed when used toward the agile process or against projects where research and development are required because the original numbers are guesses, well informed as they may be.  Reliance on just the numbers lead to ever-changing progress and goals and leads to inaccurate EMV results.  These results are often then tailored to make them look better.  If your project requires EVM reporting, there are people with the express job of sorting through the numbers and making appropriate justifications and better options when required.

Project Tracking Alternative

A far better method of Project Tracking relates back to team leadership and close communication with your development leads.  While key milestones are still needed, the very best information comes from the team itself, not numbers on a chart.  For example, if the successful project is mostly driven by algorithm success, but something happens to complicate this, the EVM numbers become almost meaningless, and success will fall back to leadership and communications.  Leadership is where Risks and Opportunities come into play as the Risk of not meeting a predicted milestone due to technical issues or personnel issues, such as emergency leave. The Risk needs assessment and any opportunities to accelerate other portions of the project.

Conclusion

Keeping accurate track of your project comes down to team leadership and the trust and open communications with your team.  Various “tools” of Project Tracking are limited in their ability to address anything but traditional waterfall projects where every step is known beforehand.  Your project is far better served with a full understanding of the problem being worked on, team leadership, and reliable communication.  Project Managers who rely on just one plan assume that everything will work as first estimated are doomed to some epic failures.

Make, Buy or Integrate – 9 November 2020 – The Iceni Team

 Not too long ago, one of the main choices in product design and implementation was the question of make or buy.  Is it more beneficial to build and maintain a product or simply buy it?  Integration can now be part of this decision space. More

 While specific components may be assembled into the final product, I would not call that integration even in the traditional question.  Integration is more of a mix of the two, made possible by software and software flexibility leaps.  As a quick example of building a new table, the making part is the custom scrollwork and finishing while the buy is the tools and fasteners you choose to use.  On the other hand, integration is more like building an application in a fixed environment, such as a smartphone.

The advantage of buying is that you have found a product that meets your needs just the way it is; therefore, do not ever fall for the trap of it just needs a little modification.  I can certainly turn a toaster into a rotisserie, but it will never make toast again.  Off the shelf, products are just that, off-the-shelf made for one specific task at which it exceeds.

The advantage of making is that you can create something for your specific need.  The only potential risks are that of expense and maintenance costs in the future.  Sometimes, it is the only way to go, however, and if you are lucky, it can become an off the shelf product to sell to others with the same problem to solve.

Sometimes you end up making then buying, as was the case with performing Fast Fourier Transforms (FFTs). At the time, no product on the market could meet the calculation speed required, so the company developed an optical processor to meet the rates.  Unfortunately, this led to many maintenance issues as the speed of light is constant only in a vacuum, and the environment tended to change with heat, weather, etc.  Then Floating-Point Gate Arrays (FPGAs) came on the market to do the job without the environmental impacts to the calculations and minimal maintenance.  Therefore, sometimes you have to build/make until technology catches up with something that can get the job done.  Similar leaps in technology can be seen in all-digital fiber-optic connections that were not only faster but could time-tag the data, replacing analog data transfers and timing circuits where the physical length of the cable had to be calculated very accurately and timing adjusted to synchronize the data.  The cautionary tale is to ensure that the new buy technology meets everything that made technology could.

Integration is unique in that you are essentially building a custom product using a known platform or environment.  It is the trade space between the two extremes and promises to get more use as the world becomes more interconnected.  An early example might be a custom spreadsheet that you made in Excel and then exporting that data into another application to complete your taxes.  Newer examples range from smartwatches that interconnect your phone, computer, and body and still tell time.  Individual components were either bought or made, then assembled, but the connectivity between devices and functions is the integration.  Further, that integration technique is useful in creating newer functions without disrupting the existing.

Concept of Operations (CONOPS) – 2 November 2020 – The Iceni Team

CONOPS is the complementary document to the requirements.  They help to drive requirements and to define who and how the client will use the system.  CONOPS is vital for a better understanding of how a system is used and the considerations that must be in place to assure success. More

 System is a relatively wide-reaching description of either day-to-day operations or a single event.  CONOPS, therefore, defines the course of action in the use of the system.  A system CONOP is the course of events, the number of people involved, and the environment.

Two widely different examples are the daily checks in space travel and a wedding.  Both require a good deal of forethought and buy-in from stakeholders.  Thus, the CONOPS are best when created when developing the requirements and drive many requirements to a better level of exactness.  Not only are the actual people involved described, but environmental factors and timelines are also defined.  Think of CONOPS as the timeline of system use.  In modern software development, these may be called Use Cases, but they are the same thing.

In space, the CONOPS will deal with the weightless and very close environment.  As such, each person may have specific duties on various sub-systems to ensure the spacecraft and crew’s safety.  Considerations must be taken into account, such as room to perform tasks, a schedule of eating, exercising, toilet use, and sleeping or private times.  These drive requirements as to the layout of the interior, range of motion, and so forth.  Similarly, a wedding must consider the bride and groom and the whole bridal party, guests, and a timeline of activities.  Questions here may be how many people to accommodate, seating arrangements, perhaps some should not sit by others, and so on.  Will there be dancing, a dinner, or both?  How do the Bride and Groom make their escape, and when are the obligatory pictures to be taken?  Although very different, both are examples of a system that must be thought out and defined early in the process.

Remember to plan how a system works and impacts standard workflow when developing requirements lest you build something no one would ever use.  

Work Breakdown Structures (WBS) – 26 October 2020 – The Iceni Team

The Work Breakdown Structure (WBS) starts with the proposal (program layout and costing) and lives throughout the lifecycle of all programs.  The WBS is essential to the success of all programs. The WBS is tied closely to the schedule showing tasks and milestones, leading to program success. More

 

During the proposal process, the WBS creation is one of the most important first steps to take. It is used to layout management, financial, technical, development, documentation, testing, delivery, and sell-off.  If the WBS is not well thought out, it will cause proposal and execution issues. When laying out the WBS, be mindful and do “no go” down to many levels.  Ensure that the levels are meaningful and help track performance.

The WBS is used to track requirements, program/task execution status, financial performance ensuring the program execution is on schedule.  A good WBS can help show a weekly, biweekly, or monthly financial performance to the lowest level helping identify overruns or underruns.  Early identification can address issues and recovery plans put in place. When underruns are identified, Project Managers can place unused funds in management reserve. 

WBS creation is something that people get better at with experience through working proposals and working on programs.  

Schedules – 19 October 2020 – The Iceni Team

Stakeholder identification and management is a vital part of the Project Management cycle.  As a collective group, the stakeholders will help form your requirements and Concept of Operations (CONOPS), any regulatory hurdles, and the sell-off of the project.  However, not each stakeholder is the same, and thus management of them will vary.  They will each have different roles, prefer different types and frequency of communication, and require individual attention.  Any given project will have many stakeholders, and treating them, all the same is a waste of your time and theirs. More

 

First, sort the stakeholders in terms of relative importance to your design and roll-out plan.  Then you can begin looking at their individual needs.  Start with categories such as:

  • Customer/Investor – the group(s) that are providing the funding
  • End-User/Consumer – those who will be using the system when deployed
  • Internal Development Team – your people who will be working to deliver the system
  • Sub-Contractors – Any outside work you will require
  • Regulatory – Represents any environmental or statutory considerations

From the point of successful sorting, you must decide when they will need to receive project progress and how they will need it.

Examine each stakeholder with empathy and data, or who are they and why do they care.  What sort of data do they need?  How often do they need it?  How do they drive the design?  Usually, the consistent communicators are the Customers, End-User, and the Internal Team; the others are just hurdles to cross.

Beginning with Customers, the main questions to ask is how involved they would like to be?  As they pay the bills, you need to give them some fair say and often keep them in communications.  Customers are also good to keep in a good standing relationship as they may be back for more, and life is so much easier if they trust you. Customers’ most significant problem is when they want to give you too much help and end up slowing down your Team, so as a Project Manager, there is a balance between keeping them well informed and safely far enough away from the daily work.

Next, the End User, most important during the design phase and to keep abreast of their activities, if their job changes, you may need to alter your course.  Also essential to keep in mind any Operations and Maintenance (O&M) tail that they will be taking on and any you may be responsible for, and again, a good rapport with them can serve you well for new requests.

Internal Team stakeholders are just as important as the other two as they build the system; you serve them best by being the buffer between them getting work done and useless meetings.  They also represent most of the detailed knowledge of your Team and can offer alternative solutions and highlight upcoming risks and opportunities during the build.  Treat your Team with the utmost respect as their success is yours, and you are much more likely to keep the Team for your next project.  It is also a good idea to pick one or two of your Team members to prepare to take over should anything happen to you and help better their advancement opportunities.

Sub-Contractors are an interesting challenge, and the amount of energy spent here will vary.  Are you buying from them and off-the-shelf products and just need to ensure it arrives on time, or are they an extension of your Team?  Either way, a good relationship here is helpful as you may desire their services again, so clear direction, prompt payment, and fair deals will keep you both on each other’s good list.

Regulators are just as the name implies; they are typically a third party to ensure that your project is compliant to existing rules, be they security, environmental, or standards.  They deserve some attention, and a good relationship will make for better, more efficient processing in the future.

Stakeholders – 12 October 2020 – The Iceni Team

Stakeholder identification and management is a vital part of the Project Management cycle.  As a collective group, the stakeholders will help form your requirements and Concept of Operations (CONOPS), any regulatory hurdles, and the sell-off of the project.  However, not each stakeholder is the same, and thus management of them will vary. More

 They will each have different roles, prefer different types and frequency of communication, and require individual attention.  Any given project will have many stakeholders, and treating them, all the same is a waste of your time and theirs.

First, sort the stakeholders in terms of relative importance to your design and roll-out plan.  Then you can begin looking at their individual needs.  Start with categories such as:

  • Customer/Investor – the group(s) that are providing the funding
  • End-User/Consumer – those who will be using the system when deployed
  • Internal Development Team – your people who will be working to deliver the system
  • Sub-Contractors – Any outside work you will require
  • Regulatory – Represents any environmental or statutory considerations

From the point of successful sorting, you must decide when they will need to receive project progress and how they will need it.

Examine each stakeholder with empathy and data, or who are they and why do they care.  What sort of data do they need?  How often do they need it?  How do they drive the design?  Usually, the consistent communicators are the Customers, End-User, and the Internal Team; the others are just hurdles to cross.

Beginning with Customers, the main questions to ask is how involved they would like to be?  As they pay the bills, you need to give them some fair say and often keep them in communications.  Customers are also good to keep in a good standing relationship as they may be back for more, and life is so much easier if they trust you. Customers’ most significant problem is when they want to give you too much help and end up slowing down your Team, so as a Project Manager, there is a balance between keeping them well informed and safely far enough away from the daily work.

Next, the End User, most important during the design phase and to keep abreast of their activities, if their job changes, you may need to alter your course.  Also essential to keep in mind any Operations and Maintenance (O&M) tail that they will be taking on and any you may be responsible for, and again, a good rapport with them can serve you well for new requests.

Internal Team stakeholders are just as important as the other two as they build the system; you serve them best by being the buffer between them getting work done and useless meetings.  They also represent most of the detailed knowledge of your Team and can offer alternative solutions and highlight upcoming risks and opportunities during the build.  Treat your Team with the utmost respect as their success is yours, and you are much more likely to keep the Team for your next project.  It is also a good idea to pick one or two of your Team members to prepare to take over should anything happen to you and help better their advancement opportunities.

Sub-Contractors are an interesting challenge, and the amount of energy spent here will vary.  Are you buying from them and off-the-shelf products and just need to ensure it arrives on time, or are they an extension of your Team?  Either way, a good relationship here is helpful as you may desire their services again, so clear direction, prompt payment, and fair deals will keep you both on each other’s good list.

Regulators are just as the name implies; they are typically a third party to ensure that your project is compliant to existing rules, be they security, environmental, or standards.  They deserve some attention, and a good relationship will make for better, more efficient processing in the future.

In conclusion, the Stakeholders come in many forms, all of which will have different needs and desires and deserve good professional relationships as it will make your future brighter.

Test and Sell-Off – 5 October 2020 – The Iceni Team

Test Planning and Development, Requirement Verification, Sell-Off, and Execution are all parts of every project and intertwined in several development stages.  Test Planning begins upfront after identifying capabilities and the development of requirements. Test Development involves Requirements review, allocation to methods, and procedures creation for verification. More

Identification of resources for testing and verification occurs at this time. Requirement Verification occurs through procedure creation, review, and execution. Sell-Off occurs when each requirement undergoes testing and is verified or adjudicated to finalize the Test phase.  Making plans upfront on how and what to test adds to the overall understanding of the requirements and CONOPS.  Since testing will occur at different levels throughout the process, test plans early are vital to ensure better and more efficient and cohesive test development

Some critical roles in testing involve not only your test team but the software and hardware engineers along the path.  The Systems Engineers and Test Engineers, sometimes the same, need upfront communications as requirements and CONOPS go through the refinement process.   This communication provides the Test Engineers with their first look at how to test the system.  Next, the Software and Hardware Engineers need to define their internal test procedures.  And finally, the Test Engineers will put together the final test plan for sell-off.

Test methods are:

  • Inspection – Observing to result. 
  • Test – A quantifying comparison of actual vs. expected results. 
  • Analysis – A mathematical proof of the system.
  • Demonstration – Just like the name, a demonstration of the system, usually used as the final sell-off of the higher-level requirements. 

These tests are further broken down into individual tests, such as load testing, usability, and security, primarily in the domain of the individual tests and as sections of the final system sell-off.

Testing is vital for a smooth-running project, be it: 1) at the beginning where it helps in the requirements and CONOPS definition; 2) the Software and Hardware engineers performing their individual test on various modules; and 3) solidify the final sell-off of your end product.  And like everything else in a project, configuration management (CM) plays an important role. If a test should point towards a design change, so be it, just make sure that change has both documentation and a reason and flowed into the other aspects of the system so that nothing is incompatible in the end. 

Leadership vs. Management – 28 September 2020 – Mike Provines

Project Managers primarily need to be a Leader with just a touch of Management.  

Management is, according to The Oxford Dictionary of English: “The process of dealing with or controlling things or people.” 

Whereas a Leader is: “The person who leads or commands a group, organization, or country.” More

The critical difference is between the word process and lead.  Every Project Manager is responsible for controlling budget and schedule; while a Leader is responsible for a coherent team that works to achieve the same goal.

Management duties include weekly or monthly tracking and reporting of various milestones and putting that package together for the Customer, internal, external, or both.  Management is most often done following the company guidance on the format of the data to be reported and predictions of completion within the allotted time—a necessary but bothersome task

Leadership is the building and maintaining the coherent team that fully understands the final goal and is motivated to achieve it.  This team may vary between the simple internal team with known people you have worked with before to the complex where the team collects internal team members, some know, some unknown, subcontractors, suppliers, and stakeholders.  A good leader will work towards mutual respect for all team members, share the credit for the success, and willing to take all blame for failure.

The Project manager’s goal should be that everyone on their core team should understand the problem and proposed solutions and believe in it.  To that end, recommend taking the time to understand the history of the problem and the new solution.  Every core member should be able to give an overview briefing at a moment’s notice on how and why the Project is underway, who it impacts and how the solution is beneficial.  Not to say that the core member need to be experts in every detail, expecting that if more information is in need, they can look to the sub-team for specific answers.  Further, a relationship of trust and respect between team members is vital.  Some rules to follow for good Leadership are:

  • Lead by example and from the front.
  • Never personally criticize an individual in a group setting; there are things you may not understand.
  • Always encourage team bonding.
  • In meetings, listen to differing opinions and consider them with the respect they deserve.
  • Never allow one person to put down another personally, but rather take them to the side to counsel them; the last thing you need is a melee in a meeting.
  • Always stand up for your team; if an outsider tries to pick a fight, remember you are the champion.  This action encourages team fellowship, and they will do the same for others, including you.
  • Always make the time to hear, offline of course, to an individual’s concerns, if technical bring them up in a meeting, when personal, keep it that way.

Keep a personal log that you review daily to help reduce risk, adjust planning, and so forth as appropriate.  Portions of this log can also help generate lessons learned for the next Project or the next Project Manager.  Keeping your team focused and friendly will almost always result in an excellent result.

Configuration Management – 21 September 2020 – Carlton Teel

What is Configuration Management?

Per Wikipedia: Configuration management (CM) is a systems engineering process for establishing and maintaining consistency of a product’s performance, functional, and physical attributes with its requirements, design, and operational information throughout its life. More

The CM process is widely used by military engineering organizations to manage changes throughout the system lifecycle of complex systems, such as weapon systems, military vehicles, and information systems. Outside the military, the CM process is also used with IT service management as defined by ITIL, and with other domain models in the civil engineering and different industrial engineering segments such as roads, bridges, canals, dams, and buildings.

Configuration Management is critical for capturing all the information about the development of a product/system from the cradle to the grave.  CM allows for the development of the process(es) needed to accurately re-create a product/system repeatedly with the expectation of having the same result/performance.  CM usually focuses on the software development aspect of the product/system; however, this is only one key aspect of the CM process of a product/system.  Using an IT as an example, other areas of concern that needs to be captured and put into CM are:

  • Hardware:
    • Make and model of a computer, network switches, fiber switches, hardware components, etc.
    • Firmware levels of the computer and any hardware components in the system
  • Software:
    • Operating system (OS) release
    • Driver versions
    • Third-party software versions
    • Compiler and library versions used to build the software
    • Build scripts and procedures
    • OS hardening (if applicable)
  • Testing:
    • Test scripts and procedures
    • Functional tests of components (e.g., network performance of a network interface card)
      • Test results on the firmware version, driver version, and any system tuning required by the hardware component.
    • Operational system test results

The information collected will aid the end-user in maintaining the system if a hardware component needs replacing. For example, the end-user will know what firmware level, if applicable, needs to be installed on the component to achieve the expected performance the system is built.

In the end, having all this information captured in CM will also allow the developer to:

  • Re-create the system
  • Produce the necessary deliverable support documentation to maintain the product/system
  • Provide confidence to the end-user that they will know what to expect from the product/system
  • Provide a rationale for each change, which is especially essential when impacts to performance, budget, or schedule need to be defended

It is also essential to track why and what else may be affected by any change.  Therefore, your CM process needs to include not only the documentation of the change but why and what or who else it might impact.  CM gives the Project the power to trace back how the design changes over time and why.

Project Management – 14 September 2020 – Mike Provines

What does it mean to be a Project Manager?  What are the key attributes and responsibilities?  To answer these questions, it is first required to assume the responsibility of being the ultimate lead for the Project.  Being the lead means that you fully understand the Project, why it is worthwhile, and what it hopes to achieve.  Being a leader does not mean that you know everyone’s work details, but you had better understand the role that each component plays.  More

Think of the Project Manager as the Producer of a film.  The Producer is in charge of hiring all the right people, the Director, the actors, the scriptwriters, the publicists, when and where the film is going to show, every aspect of the entire Project.  Also, the Producer must find the money to fund the movie; these are the Executive Producers and make sure they are happy along with the rest of the cast and crew.  So, it is with a Project Manager, not only do you have to have a satisfied end-user, but you must also have to keep the Customer happy with the cost and schedule and make sure the team works and plays well together.

Before taking on the role of a Project Manager, do some homework on the various technologies and skill sets you will require for the lifecycle of the Project.  First, one must deal with the Customer who will be funding the Project.  The Customer must believe that the Project is worth their money and resources.  The Customer can be internal or external, so the Project Manager’s job will be first to convince them they care and trust that the Project will be a success.  An example of an internal Project might be a change in the business infrastructure to allow for a more secure, robust, and flexible system that will enhance operations and keep the employees interested in their jobs.  An external Project will be a product delivered to end-users that must be satisfied and receives funds from outside the company.  Either way, the Customer, those with the money, need to be convinced the Project is worthwhile and produce the desired results within the amount of money they are willing to spend.  Once this is established, the real challenge begins.

The Customer will have a vision and budget and schedule of what they think they would like to see happen, often given by very high-level requirements, maybe just a couple of sketches and a thought of what something ought to cost and how long it should take.  Typically, the Project Manager will not have near enough detail to do anything.  At this point, involve stakeholders.  You have the first already, the Customer.  Now you will need the End Users, your resources, people and materials, and a lifecycle plan that will succeed.  Keep in mind that all stakeholders must also believe in the Project’s success.  The constant asking, listening, and two-way feedback is a job within itself.  In addition, you will be responsible for the management of the budget and schedule.

A stakeholder is a broad field, and they all must be kept engaged and confident in success.  There will be many pitfalls as well as some lucky breaks.  The Project Manager gets to juggle all of this daily.  It is essential to make friends with your key personnel; this goes from the Customer to your internal leads, and your sub-contractor leads as well as the end-user.  A quick weekly meeting on progress is a good idea, just to keep ideas and schedules flowing.  Also, get to know, especially your Customer and internal people well; take some time to touch base individually with these people to both keep them focused and to share any thoughts they may not want to bring up in the group.  Be prepared to bring any issues to the group meeting as if they had come from you if the individual asks.  The critical thing to keep in mind is that you are the leader.  A good leader is especially important in remote managing. For that, it may be wise to have smaller meetings with individual teams once a week to make sure that everyone is still striving for the same outcome and that there are no upcoming risks that will become issues.  And one last thing to keep in mind; don’t keep secrets from your team, boss or customer.  Things can sometimes go awry and hiding them will only set up something worse, so if you foresee budget, performance or schedule issues on the horizon, get the team informed so that an answer can be found or otherwise mitigated.  Things happen, and plans may change, but surprises are bad.

In Conclusion, being a Program Manager means that you are leading an entire production; your job is to make sure they are a team, regardless of who signs their checks.  You are responsible for knowing the problem and have a reasonably good understanding of how it will all come together.  I suggest keeping a personal log to learn from each project, it will also make producing lessons learned easy, but the log for be yours, take time to review it each week and learn from it.  If you are told that the only duties a Project Manager has is to keep spreadsheets of budget and schedule you end up ignoring your team and yourself.  Not only will this result in mediocre results and raises, but it takes the fun out of the job.  A Project Manager’s goal should be to learn and care more, and it also makes it fun.

What is Risk Management? And Why should you care? – 7 September 2020 – Randy Katz

What is a risk? – A risk is an unexpected or unplanned event that, if it occurs, will negatively impact a program, product, system, or any other element of your business. In these unprecedented times, Covid-19 is one of the largest risks we have seen in over 100 years. With companies going bankrupt, unemployment rising, and people dying as a result of this risk, it is clear that we have failed to manage the spread of the virus, increasing the probability of occurrence and the resulting disastrous consequences. More

I use Covid-19 as an example of a risk with widespread impact, to emphasize the importance of mitigating risks to decrease their probability of occurrence and to reduce the consequences of their impact. This is a good segue way into explaining the process of Risk Management.

What is Risk Management? – Risk Management is a well-defined process to identify risks early on in the program life cycle and to generate a plan to reduce the impact of these risks if and when they occur. The plan intends to reduce the probability that the risks will occur and to decrease the consequences or adverse effects if these risks arise.  The Risk Management Plan consists of mitigation steps for each risk to reduce the Probability and Consequence of that risk. Risk Management is not free, as it requires resources to define the risks, track the risks, and to mitigate their probabilities and consequences. If Risk Management is implemented correctly and efficiently, then the costs of mitigating the risks are significantly less than the costs of realizing the risks. In other words, investing a small portion of the program budget, typically referred to as management reserve, in running a well-managed Risk Management process, quite frequently saves the program money by avoiding the costly occurrence of realizing the risks. The cost savings between the impact of recognizing the risks and the management reserve budget can offer additional capabilities to the Customer, improve the profit margin or both. Imagine how an effective Risk Management Plan consisting of effective and detailed mitigation steps for a viral pandemic, even at the cost of Billions of Dollars, could have saved millions of lives, 10s of millions of jobs, and Trillions of dollars of increased Government deficits

This is just an introduction to Risk Management and why you should care. Follow future blogs to get more details on how to implement the practice of Risk Management and to gain insight on available software tools to manage your risks. Also, learn how to create Opportunities as part of the Risk Management process to reduce costs on your programs further and increase your profitability. 

Let the Iceni Group teach you more about Risk Management as a best practice in running your business.

Cost Savings (4 Parts) – 3-31 August 2020 – Freelann Clark

Over the years, I have had the opportunity to go into numerous public and private companies to review and evaluate their financial performance. This is going to be a four-part blog addressing easy cost-saving steps to increase the business’s bottom line financial performance.

When looking at a company’s financial performance, one needs to look at the overhead cost of the business.  Overhead costs break down into four different categories: More

  • Category 1: Employee Expenses (e.g., cell phones, beepers, home network, wi-fi, laptops, tablets, etc.),  
  • Category 2: Facility Usage (do you have to much space, are you maximizing your space),  
  • Category 3: Employee Insurance (need to consult outside firms and get the best value), and 
  • Category 4: Retirement Benefits. 

Category 1: Employee Expenses

Working with public and private companies over the years, I have made note that employee expenses are not closely monitored.  These expenses include the following cell phones, beepers, home networks, and WIFI, laptops, and tablets, to name a few.  Believe it, or not some companies still have pagers and cell phones that are not 100% utilized. Since we now have people working from home, employees are expensing Internet providers and printer supplies.  Also, there are laptop/tablet refreshes.  All of these expenses are valid to a point.  Here at the Iceni Group, we have proven methods to determine if items are being utilized and needed.  We also look at how employees are expensing their home office and if items are not solely for the company use.   By reviewing the above and other expenses, savings go straight to the bottom line.

The above examples are just a few of the items that the Iceni Group looks at. The Iceni Group has proven processes that we use to lower costs and improve the bottom line.  

Category 2: Facility Usage

Over the years, companies have, for the most part, always supplied a desk or office for all employees. While this was a nice gesture, it wasted dollars on unused facility space.  Companies also have a requirement to store records for seven years. In most cases, companies forget, and items are stored forever.

In today’s environment with COVID, companies are letting employees work remotely and is proving to work well. I know of one case in speaking with the CEO of a company headquartered in Atlanta; they have gone from having space for 600 employees down to 45 business types keeping the company running and four conference rooms for employees to use.  This alone if saving around $30K per month.

Another realization from a different CEO we helped was discovering they had seven warehouses. In visiting the warehouses, we found four were empty, and three had paper statements that were 15 years old.  We removed all the paper and shredded it and did not renew the leases on the seven warehouses, putting $14K per month to the bottom line.

Category 3: Insurance

One of the most significant expenses a company faces is Medical Insurance.  Large companies have a huge advantage; they are able to leverage sheer employee numbers to get lower insurance rates. Smaller companies are at a disadvantage since small numbers do not allow for reasonable pricing.  Here at the Iceni Group, we have worked with insurance consultants to look for groups of small companies to combine them to increase employee numbers and get better pricing.

Category 4: Retirement Benefits

Over the last few years, I have approached by Executives about why their new workforce leaves after 3 or 5 years

After talking with new employees with 2 to 8 years of experience out of college, they all said the same thing.  There the only retirement is their 401k.  The days of companies offering defined retirements are long gone.  So, after vesting, they move to another company getting a 5 to 10% raise plus 401.

After talking with new employees with 2 to 8 years of experience out of college, they all said the same thing.  There the only retirement is their 401k.  The days of companies offering defined retirements are long gone.  So, after vesting, they move to another company getting a 5 to 10% raise plus 401.

Requirements and More – 27 July 2020 – Mike Provines

Functional requirements are not enough – a project manager must not only have requirements but understand what is intended by them.  A good project manager will do this in two ways: requirements decomposition and Concept of Operations (CONOPS) that are agreed upon by the stakeholders.  Whether you are in an Agile or Waterfall development, this upfront work will pay off.  More

This isn’t to say that things cannot change, but all changes should be documented including the change, the effect(s), and why via Configuration Management, which is the subject of another blog.

Many times, you will be given a set of requirements and expected to deliver on them.  These requirements are often non-specific and difficult to test.  Remember that the requirements are not only the problem you are solving; you will also need to know how to prove and sell off your final product.  This is where CONOPS is essential. Additionally, knowing more details for the requirements will serve you well.  It is always worth the time to sit down with the stakeholders, especially users and the manufacturers, to make sure everyone knows – and agrees – about what the final product will be.  

Not doing this can lead to significant project issues. 

Take, for example, a situation in which the requirement states that the system shall be able to execute ten searches for 100 users within ten seconds at once.  If you test this by performing the same ten searches using 100 simulated users, you will sell off this requirement.  Still, in real usage, the system will crash when ten people in actual usage execute three different searches.  If you had met with users and developers, they would understand that the system needs to support multiple people doing random searches, which would have driven your test criteria.  

In the end, the up-front time spent in truly understanding the requirements, from the stakeholder’s view, will lead to better results and cost savings as you make the system once and satisfy requirements.  There have been many contracts when a customer asks to just sell off the system without making CONOPS a deliverable because of the cost involved.  Still, as a project manager, you will want the CONOPS as well as a sit down with stakeholders to understand what they meant by the requirements and how they expect to use the system.  Your other option is a significant cost and schedule overruns and angry customers.

Let the Iceni Group teach you about this best practice.

Lessons Learned – 20 July 2020 – Mike Provines

Every project usually delivers lessons learned found during the project, unfortunately, most of these are the lessons learned from the previous project, renamed and may be updated.  This process misses the entire point of developing lessons learned.  Lessons learned should be a deliverable to you and your company, not just extra paperwork to make the bosses happy.More

Repeated Lessons Learned are useless; no one ever reads them, and they tend to fall into the same mistakes that were documented long ago.  At the beginning of every project, a good exercise is to review lessons learned from the previous projects, which will kick-off. 

Lessons learned will hopefully never repeat. That said, allow for good things that happened in your lessons learned, so you can repeat success while minimizing repeat mistakes.  This is what is valuable to you and your company.  Never fall into the trap that they need to be a certain length, either. Hopefully, lessons learned, for mistakes, get smaller as time goes by since you and your company are getting better.  Brand new projects will likely be a little longer since it was a new effort and different from what you have done before, and never forget the good things as well.

In the end, Lessons Learned are not billable to the client, they are for you, think of them of a log of the project, what went well, what went wrong, and thoughts on both.  So in the end, you should endeavor to not repeat mistakes and at the same time, experiment with new approaches, just document them for future reference.

Let the Iceni Group teach you about this best practice.

System Engineering Processes – 13 July 2020 – Freelann Clark

Over the course of my career, I have been fortunate to work for some very well-respected defense contractors.  What did they have in common?  Strong system engineering, effective and thoroughly documented software engineering processes, and well-designed structures that enabled success in the proposal process and program sell-off.More

After 20+ years working in the defense industry, I was approached by a New York-based private equity firm to be part of a turnaround team in the commercial sector.  After accepting the position and being briefed on the four companies they wanted us to help, it became obvious that commercial firms did not have robust system engineering or software engineering processes that the defense sector uses.  After spending a few weeks at each company, we discovered that their Statement of Works (SOWs) did not cover all the requirements. An additional weakness was that they contained minimal sell-off criteria.

Due to their deficient SOWs and negligible sell-off criteria, all four companies were experiencing program cost overruns totaling $13+ million.  It took months to get the program to sell-off and make the customers happy.  During this time, we implemented a strong system and software engineering processes to protect both our companies and the customer. 

Here at the Iceni Group, we are subject experts in system and software engineering processes and proposal generation and sell off criteria.  Our team is ready to help your company keep customers happy, gain additional business, and have accounts you can reference.

Software Excellence – 06 July 2020 – Mike Provines and Carlton Teel

The aim of software excellence is to deliver the best product.

Software excellence requires adhering to an intentional and deliberate process that upholds industry best practices.More

The process must begin with comprehensive up-front engineering that includes designing the functionality of the software, establishing variable standards (naming, determining global vs. local), and the like.  While it is all too common to encounter software containing code that is hobbled together, software should run more like a high-performance piece of machinery.  This fine-tuned efficiency is marked by three key features. The first is a thorough understanding of what the software does.  The second is knowing what data comes in and what data leaves.  Lastly, and perhaps most importantly, is enabling maintenance by the originator or by the customer.

When it comes to coding, consistency is critical because it gives the originator, or a new employee, a good idea of what he/she is looking at during maintenance or if the code needs to be shared with employees in other disciplines.  Additionally, the importance of the prolific use of embedded comments and test points serves two purposes – isolation of potential problems and as the basis for training, which can be for software use or in the training material.  It also facilitates the reuse of code which has significant benefits. One is that when similar tools are developed, existing software can be used as a template.

Code reviews are an overlooked but vital characteristic of software excellence.  Code reviews facilitate sharing the code and equipping teams to identify more elegant solutions.  A good code review process should make it easy for even non-coders to understand the data flow and abilities of the code.  Proper code reviews can significantly shorten the time that the entire software team must be present in meetings which boosts productivity and benefits the company.

Another crucial step is to engage the users or their proxies when there is a user interface to the application.  It must make sense to users/operators, and their opinions may differ from those of the software developers.  User acceptance is critical to the success of an application.  After all, the best results for the customer can only be achieved if the software is utilized.

While the Iceni Group is interested in setting up and teaching these methods, we also incorporate them into all custom work.  Want to learn more about how software excellence can benefit your company?  Let us talk you through how it can make a difference. 

Soft Skills – 30 June 2020 – Mike Provines

Soft skills – non-technical skills that enable effective and harmonious interaction with others – are vital to organizations and can impact culture, mindset, leadership, attitude, and behavior. Soft skills include advanced communication, negotiation skills, empathy, leadership and management, teaching and training, adaptability, and continuous learning.More

The pandemic has accelerated new workplace environments including more remote teams. Maintaining team efficiencies and promoting adaptation is dependent on the development of soft skills. 

Knowing your people and the project are essential to success. With the trend away from long-term jobs completed in a single location, companies must be able to effectively change employee processes and behaviors. To make these changes less daunting, both managers and employees will need to embrace new forms of soft skills. For example, short team meetings can be followed by “walk-around management” or one-on-ones to identify any upcoming risks and diffuse them before they became issues. 

Effective soft skills are a two-way process – in one-on-one meetings, the manager and employee must feel comfortable enough with each other to honestly discuss the project and proactively convey personal responsibilities that may hinder the job.  Another example is companies embracing different work schedules for employees. Let’s face it: there are morning people and evening people and people who work best during the middle of the day. Flexible work schedules allow employees to work when they are most productive. Companies also benefit by empowering their employees to achieve the right balance between work and household responsibilities such as taking care of children, shopping, cooking, or even walking the dog. 

As comfort with one-on-ones increases, employees will also become more comfortable with their group. Although I think it is still important to keep the meetings short, there are times when lengthier meetings are more effective such as when a team is getting comfortable with each other. For example, an employee may want to share about how a baseball almost broke his son’s cheekbone over the weekend. The work team might spend a few minutes throwing out ideas for a really good story. The boy can tell other kids when he returns to school. Likewise, stories about how things have previously gone well or poorly spread camaraderie and knowledge, and as such, are also important.  As for teaching, training, and learning, developing standards on the level of detail, preferred format, and the like will become even more important. This is especially true as you grow and bring on new people who reside in other locations. Think about the ways video conferencing has allowed us to share stories such as the reasons employees choose certain backgrounds. The thing to remember is meeting first, socialization second. Most of all, soft skills empower you to make meetings a pleasure that employees look forward to instead of a chore that they dread.  

With the accelerated coming of the new workplace, soft skills are increasingly important. Effective soft skills not only make newcomers feel welcome, they greatly reduce turnover rates because a good team is the best reason to stay.

Leave a Reply

Your email address will not be published. Required fields are marked *