Skip to main content

Tag: Best Practices

On-Site vs In-Office Experience – Word to the Interns

As you exit or take a break from your learning institutions and transit to the industry, you carry a lot of fantasies in your head about the good and comforting expectations that your tutors lied to you about. The construction industry in this country is not thoroughly regulated. Doctors have very good advocates that make their line of work look civilized and even indoors—what you call white collar. Your first test on the field is your capacity to bear what happens on the ground compared to what you have been writing in your books.

For the intern, who is either an Architect(Arch.), Quantity Surveyor(QS) or Structural Engineer(Eng.), the situation is not so tough as you will apply about 72% of your theory on site. The incoming project managers have a tough ride as you only apply 28%. As the engineer or Qs get on paper to do his calculations, you will sit on a corner and begin shaking your head in all directions, scanning for solutions on how to contain an emerging risk on site.

 

I recommend that you begin your journey as a site guy rather than an office guy. A lot of events happen on site that you will never get to experience while sitting in the office enjoying the free wi-fi and 10 a.m. tea. First, you will be able to expand your network through other professionals that you interact with through site meetings. Second, you will have high chances of landing a direct client, as they prefer to see the quality of your work rather than your academic portfolio. Third, you will be able to appreciate the role of builders, as you will feel a sense of pride as they transfer your work to the ground.

For architects, you will appreciate how the elements of design are practically implemented. For example, space, function, mood, and perception. For engineers, you will need to check how the design mix ratio is practically achieved as well as the reinforcement patterns in your drawings. For quantity surveyors, you will be able to do re-measurements for valuation purposes and breakdown your bill of quantities into a schedule of materials, which is the only document that suppliers understand.

 

Advertisement
[widget id=”custom_html-68″]

 

If you continue forcing your way to offices to only take care of paper work, then you are in the wrong industry. Leave that to accountants and politicians. From my experience, the office guy who rarely associates himself with the construction bit is the main cause of conflicts, starting from project inception to handover. He creates a moody environment between the consultant and the builder without appreciating the importance of “alternative measures” on site, especially where the situation is not so critical.

For example, if you, as the engineer, sit in the office designing and checking the suitability of your structural analysis just using software and fail to come on site, this is what happens; assuming you indicated bar x for a column and you are briefed that such a bar is currently out of stock in the market, what will you do? Because you want to be bossy with no tolerance to brainstorm with the site guy, you end up ordering for work to be halted until bar X is restored. The client will term you incompetent because you lack a versatile mind, thereby causing an unnecessary delay to the project. If you were the professional who was a site guy, you would let the builder continue with another bar, but in such a way that the purpose that was to be served by bar X is still maintained.

 

As I conclude, there is a common Chinese proverb that says, “What you hear, you forget; what you see, you remember; what you do, you understand.“ All are lessons right there. When you also go to the site, don`t just be there to whirl your eyes around. Take that dumpy level and proceed with setting out, obviously with some guidance. If you don`t understand, ask the builder, and you will be a complete construction prodigy.

Adapting Agile Principles for Successful Maintenance Hand-Overs

Over the 20+ years since the Agile Manifesto was created, more and more organizations see agility as key to success, especially for software development. Agile methodologies have revolutionized the way teams approach software development, emphasizing flexibility, collaboration, and continuous improvement. Ideally, there are Product Teams that handle development and maintenance throughout the product’s lifecycle. But what happens if development and maintenance are handled by separate teams?

This scenario can be problematic, especially if the teams are using are using different methodologies, or belong to different organizations (e.g. in-house and contractor teams). What happens when it’s time to transition control of a software project from the development team to the maintenance team? Can Agile principles be applied to facilitate successful hand-overs? In this article, we’ll explore how Agile principles can be adapted and applied to ensure smooth and successful software transitions.

 

Understanding Agile Principles

Before we delve into how Agile principles can be adapted for software transitions, let’s briefly review some the core principles of Agile methodology. Agile is built on four foundational values and twelve principles, as outlined in the Agile Manifesto. These values and principles emphasize:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan (flexibility)

 

Adapting Agile Principles for Transitions

Now, let’s examine how these Agile principles can be adapted and applied to facilitate successful software transitions:

  1. Flexibility: Agile methodologies prioritize flexibility and adaptability, allowing teams to respond to changing requirements and priorities. Similarly, in software transitions, flexibility is one key to navigating unforeseen challenges and adjusting plans as needed. By adopting a mindset embracing change, teams can proactively address issues and adapt their approach to ensure a smooth transition.
  2. Collaboration: Collaboration is a cornerstone of Agile methodologies, with teams working closely together to deliver value to customers. In the context of software transitions, collaboration between the development and maintenance teams is essential for success. By fostering open communication, sharing knowledge, and working collaboratively to address challenges, teams can ensure a seamless hand-over process.
  3. Continuous Improvement: Agile methodologies also emphasize continuous improvement, with teams regularly reflecting on their processes and seeking ways to enhance efficiency and effectiveness. Similarly, in software transitions, teams should evaluate their transition processes, identify areas for improvement, and implement iterative changes to optimize the hand-over process over time.

 

Advertisement
[widget id=”custom_html-68″]

 

Applying Agile Practices to Transitions

In addition to adapting Agile principles, teams can also apply specific Agile practices to facilitate successful software transitions. Some key Agile practices that can be applied include:

  1. Iterative Planning: Adopting an iterative planning approach to break down the transition process into manageable iterations, with regular checkpoints to assess progress and adjust plans as needed.
  2. Daily Stand-Ups: During the transition period consider holding daily stand-up meetings, where team members share updates, discuss progress, and identify any impediments. The goals is to facilitate communication and alignment between the development and maintenance teams.
  3. User Stories: Creating user stories to capture requirements and priorities from the perspective of the maintenance team can help ensure that the transition process is aligned with the needs of the end-users. Even more importantly, user stories that include updating and maintaining the software and likely rule or data updates will improve the maintainability of the software itself.
  4. Retrospectives: Conducting retrospectives at key milestones during the transition process allows teams to reflect on their experiences, identify successes and challenges, and brainstorm improvements for future transitions. These should also be communicated across teams and product groups.

 

Applying Agile Principles in a Software Transition

To illustrate the application of Agile principles in software transitions, let’s consider a hypothetical case study of a software development company transitioning control of a web application from the development team to the maintenance team:

  1. Flexibility: When unforeseen technical challenges arose during the transition process, the development and maintenance teams collaborated to adjust their plans and implement creative solutions, ensuring a successful hand-over despite the challenges. This included adjusting target dates and budgets for both teams to provide the time and resources needed.
  2. Collaboration: Through regular stand-up meetings and collaborative planning sessions, the development and maintenance teams worked closely together to share knowledge, address issues, and ensure alignment throughout the transition process.
  3. Continuous Improvement: Following each milestone in the transition process, the teams conducted retrospectives to reflect on their experiences and identify opportunities for improvement. By implementing iterative changes based on these retrospectives, the teams continuously optimized their transition processes over time. These were shared with other teams, along with tools, templates, and tips that had proven useful during the transition.

 

Conclusion

In conclusion, Agile principles can be effectively adapted and applied to facilitate successful software transitions from development to maintenance. By embracing flexibility, collaboration, and continuous improvement, teams can navigate the complexities of transition processes with confidence and ensure a seamless hand-over that meets the needs of end-users. Through the application of specific Agile practices and a commitment to Agile values and principles, organizations can optimize their transition processes and set the stage for long-term success in software maintenance.

If your organization uses Agile methodologies with development and maintenance handled by different teams, how are transitions handled?

The Karma of Postponing Due Diligence

There is a trade-off between doing work now and postponing it until you are forced to do it.

The law of karma says that what you do and don’t do causes a ripple effect. So, be careful to avoid the unwanted consequences of putting off review and assessment, risk management, planning, project administration, and resource management work.

 

Due Diligence

Due diligence is the opposite of negligence. In finance, project, and acquisition management, it is the effort to collect, analyze, and use data to make decisions. Due diligence is the work to collect, assess, prevent, mitigate, and account. In project management, it is the process of deciding whether to pursue or pass on a project based on a risk-reward assessment. It seeks to determine if the project is feasible, legal, ethical, and profitable. From a project and process management view, add planning, regular maintenance, and quality management to the definition of due diligence.

Bypass due diligence and the risk of failure goes way up.

 

Accounting and Due Diligence

Doing my tax accounting reminded me of the importance of the accounting part of due diligence and the understanding that not doing accounting and regular status reporting makes the rest of due diligence far more difficult than it needs to be.

Every year I resolve to take the time to clean up my data and set things in place for a far easier next year. But it is already March and I’d have to spend even more hours dealing with this ‘stuff’ when I have many other things to do to catch up for all the time I spent on the taxes. Then because I have so much else to do, I do not take the time to regularly do the accounting that would make taxes easy, even if not pleasant.

I postpone the effort and each year I repeat the pain.

 

Project Management

For one reason or another, we often put off doing unexciting and easily postponed chores.

With the pressure to “act now” and get our projects off the ground, we often find that risk-reward decision-making is given only cursory attention or bypassed altogether. Amid a dynamic complex project with tight deadlines, limited resources, and “problems” the only thing that matters is getting the work done, now. Anything else is a distraction.

This kind of heads-down, undistracted, focused work on a project can be useful. However, if you are working without regularly stepping back, you and your organization will suffer. If you think and act as if doing status reports, risk management, communication, human caretaking, and project accounting are distractions, think again.

 

Project performance includes Project management. Due diligence during the project means doing:

  • project accounting – cost and effort tracking, issue logs, status reports
  • regular quality assurance/process-focused meetings
  • risk management
  • quality control
  • communication
  • human caretaking (stakeholder management)

Above the project level, in the higher-order process, due diligence means:

  • process management – making sure the process, methodology, standards, templates, roles, and responsibilities are as best as they can be
  • portfolio management – making sure that the right projects are being initiated and realistically scheduled to avoid overwhelming resources and taking on projects that are likely to be disappointing.

 

Advertisement
[widget id=”custom_html-68″]

 

The Higher-order Process

When we refer to the project level and above, we recognize that projects are being performed within a higher-order process, which includes process and portfolio management, environmental conditions, and resource management. Both the project and higher levels are important, and they are interrelated. However, given the nature of organizations with short-sighted priorities, the higher-order process is often overlooked.

The higher-order processes are complex and operate in multiple dimensions such as portfolio management occurring in the context of organizational strategy, market conditions, regulatory issues, and more. The benefits and costs of doing and not doing due diligence at this level are not immediately realized. They make themselves known when something goes wrong, and the problem cannot be explained by and resolved at the project level.

For example, your project resources may be taken away and reassigned to another project causing your project to be delayed. If senior stakeholders are ok with the delay because it was factored into their decision to remove the resources, then there is no problem. But if this happens frequently across multiple projects it is a sign that the project portfolio may not be being effectively managed.

 

If you do not take the time to evaluate the legal, budgetary, risks, and reward factors of a project, the consequences are not felt until the project fails or a regulatory body steps in to put the brakes on. If project performers are constantly complaining about having to do useless work on administrative tasks, it may be a sign that procedures and templates need to be reviewed and repaired, performers need to be better trained, or that the wrong methodology approach is being used.

Fine-tuning or more radically changing the higher-order process affects the quality of individual project performance.

 

Project-level Due Diligence

Accounting within each project is part of project management due diligence. Every team member, not just the project manager, must allocate time and focus attention on tasks that may seem to be distractions from the so-called “real work.”

Project accounting is done to satisfy regulatory and administrative needs, for example, knowing how money has been spent and resources used. In addition, stakeholders want to know what is going on and how it is affecting their expectations. Will the project be on time and budget? What events have occurred that can get in the way?

But that’s not the only reason. Project accounting sets the stage for due diligence at a higher level. It leaves an audit trail with the data needed to refine portfolio management decision-making and methodology assessment. With project-level reporting comes the ability to look back at what happened to learn from it. Hindsight is not 20-20 unless there is a record to review. Memories are imperfect. How will the data from this project influence decision-making at a higher level?

 

Commitment and Follow-Through

The bottom line is to build due diligence activities into work plans and commit to following through with effective portfolio management decision-making, raising the consciousness of stakeholders, and ongoing refinement of the project performance approach.

Brewing Success: Managing Your eLearning Project One Cup at a Time

Coffee is a staple of my morning routine.  With little deviation, I make my coffee as soon as I sleepily saunter into the kitchen.  I don’t think much about it, the process is nearly hard-coded at this point: choice of favorite mug, mug placed, coffee prepped, brew cycle on- then I await the pop-pop-popping of hot water as the sweet aroma fills my kitchen. My brain is hyper focussed on both the sounds and smells like a Pavolivan trained dog awaiting the liquid award.  Then finally, I add cream and a touch of honey (yes honey, it’s delicious!) and after my first sip, my morning is ready to begin.

 

I get it. I’m in a rare class of those who need this cup of coffee to go beyond the simple, great, I have coffee.  I admittedly spend a lot of money on this caffeinated nectar.  It’s my one true pleasure each morning. I have a deep appreciation for connoisseurs who hone their skills and master the art of selecting beans, grinding them to perfection, and brewing a rich, flavorful caffeinated beverage. I read about coffee entrepreneurs and love to smell fresh beans when I’m in a coffee shop.  I even enjoy reading the descriptions of flavors: medium body with tasting notes of nutty, sweet chocolate, mild citrus and a bright finish….yes please, I’ll have a cup of that!

 

I realize that for the vast majority of the population, the process behind an excellent cup of coffee doesn’t really matter, it’s about the end result done right.   Yet one morning, I started thinking about both my morning routine and the overall coffee process, going from a bean in a field to a liquid in someone’s cup. And that’s when it hit me that the process of making coffee bears a striking resemblance to eLearning project management.   As it happened that morning, I had a busy day of deliverables and thought to myself, “huh, as clients receive their final deliverables, they’re likely unaware of all the careful planning, execution, and evaluation that goes on behind the scenes. They want their deliverable, done correctly and as expected”.   So I set out to write about the two processes and their similarities.

 

Selecting the Right Beans (Project Initiation/Needs Assessment)

A high-quality, aromatic coffee bean sets the foundation for a rich, silky cup of Java and a well- organized pre-project launch process is paramount to the success of an eLearning project.

For example, a coffee’s success includes bean variety, the growing region, climate (including altitude) and how the beans are harvested and processed.  Typically, there’s no need to think about anything else in the process. Sound familiar?

 

As PMs, the project initiation phase is arguably the most critical stage of the entire project.  Above all other tasks, a PM’s job is to review and/or confirm the target audience, determine what, if any constraints or risks are present, understand scope, draft a schedule, confirm resources and ensure that all source materials were shared. In other words, conduct a thorough needs assessment.   An air-tight project initiation sets the stage for a balanced and mellow project experience. Again, if done right, there’s no need for your learners to think about anything else in the process.

 

Measuring and Grinding (Project Planning)

Precision is key in both coffee and project planning. How one grinds coffee beans will play a significant role in the flavor, aroma, and strength of your final drink.  If your beans aren’t measured correctly before grinding, or if the grind size doesn’t match the intended strength, that cup of coffee will taste acidic, weak, or sour, all things I cannot tolerate.

 

In eLearning, the best way to avoid a weak project finish is early preparation to ensure that all team resources are informed of the project objectives, deliverables, schedule and risks. An eLearning project is only as successful as the individual parts.  The more project information a PM shares with the project team members, the higher the probability of success.  Kickoffs are the best way to communicate with your project teams.

 

Kickoffs ensure that your team understands the schedule, the deliverables and that everyone knows the part they’ll play in the project.  It’s a time for the team to ask questions, get to know each other if they don’t already, and to understand accountability for the project success.  Projects started without kickoffs often go sideways because they’re missing precision from the start.   Take the time to measure the project needs beforehand, so that your project begins from a position of strength.

 

Advertisement
[widget id=”custom_html-68″]

 

Power on- Whirring, Sizzle, Gurgle, Drip! (Official Project Kick-off)

Few things are better to coffee lovers than hearing the sound of the coffee machine preparing for your morning brew. It’s surely my favorite part, as I detailed at the start of this story.

 

The official kick-off with your learning team is akin to powering on your coffee machine.  Kick-off meetings are the time to confirm project scope, timing of milestones, agreements around project responsibilities, establishing meeting cadence, verifying source material status, and highlighting risks.  Kick-off meetings set the foundation for a strong project start.

 

The best way that PMs can level-set expectations is via note-taking.  Holding everyone on a client call responsible for their individual or collective parts is key, and live scribing is highly suggested so that the collective team agrees to action items and deadlines.  With the advent of AI-based tools that are creating quite the sizzle in our industry, note taking is easier than ever before so there’s no need to skip this important step!

 

Brewing (Project In-Flight, Monitoring & Control)

Obviously, the best part of the brewing process is your satisfying cup of coffee.  The preparation of your coffee beans invites the flavors from coffee grounds, and at that point, your coffee should brew as expected.  Still, like any process, problems might arise.  For example, the water temperature (targeted between 195°F to 205°F) could be off, or the wrong type of brewing method is used for the ground type which would heavily influence the role in flavor, or worse yet, user error- inserting the wrong sized filter or not measuring the water correctly.  Keeping a close eye on the brewing process throughout and adjusting parameters as needed is the best way to achieve and brew the perfect cup.

 

Similarly, an eLearning project that is meticulously and methodically organized (during initiation and planning), should percolate to an ideal state, assuming the PM’s involvement includes excellent communication, detailed awareness, shared notes and prompt resolutions.   Regularly assessing project progress is critical so that you can identify and rectify any issues quickly.  Incorporating feedback from stakeholders is an ideal way to glean that your near final product is meeting/has met expectations.

 

Ask open, thoughtful questions during status meetings that begin with “How”, “What”, or “Tell me” as examples.  Sending short (3 question max) surveys mid-project works too.  Dropping a quick email that simply reads, “I am interested in hearing your feedback around how the project is progressing to date” could glean rich insight of an issue that may have not been covered during a standing meeting.

Enjoying the Final Cup (Project Closure)

Finally, it’s time to serve your eLearning project like a perfectly brewed cup of coffee. Present the finished product to stakeholders and ensure they have the tools and knowledge to make the most of it. After successfully conducting LMS testing and launching, your project is complete.  Celebrate your team’s hard work and savor the sense of accomplishment.

 

And so, much like brewing a good cup of coffee, managing an eLearning project involves distinct phases, each crucial for a satisfying end result. Skipping or rushing through any phase can lead to a less-than-desirable outcome. By carefully tending to each step, eLearning project managers can ensure a successful and effective learning experience for their audience.  If you brew your eLearning projects with the same care and precision as you would your favorite cup of coffee, you’ll serve up excellence every time.

The Rhinoceros In The Room (Risk Analysis and How to Tame Your “Unicorn”)

Imagine going to the pet rescue organization in your town to get a new pet, and you look at several adorable dogs and cats, and then the staff person says, “Well, there’s one that we’re not sure we’re going to be able to find a home for. Would you like to see him?”

You’re there to help make a rescue and get a new furry friend, so you say, “Of course!”

The staff member takes you to the end of the row, where there’s an enormous pen with a rhino inside.

You say, “That’s a rhinoceros!” as though the staff person didn’t know that already.

They say, “Yeah! He has a horn. They make great pets because they always go to the bathroom in the same place.” (This is true, by the way.)

You say, “Yeeaaaah…but he weighs 6,500 lbs., has a horn, and can run 30mph.” (This is also true.)

They say, “But they go to the bathroom in the same place every time. Think of how much easier that is than cleaning up after a dog!”

 

It’s a comical episode, but we often do the same thing in risk analysis. The temptation is to come into risk analysis with pre-conceived notions, or even just so intent on committing to the project as is we’re unaware that’s not a unicorn staring us down. Consequently, we discuss how an Australian Shepherd can get bad hips late in life but forget that a rhino can destroy your house by turning around when you call his name.

So, let’s talk about how to recognize the rhinoceros in the room.

 

Overview

Risk analysis is the process of identifying, assessing, and prioritizing potential obstacles or stoppers before they derail your project. It involves a meticulous examination of what could possibly go wrong, the likelihood of such events, the potential impact of those worst-case scenarios, and the strategies for mitigation. We must foresee the unforeseen, prepare for the unpredictable, and make sure that a project is not merely feasible, but in the worst case will not harm business continuity or exceed allowable energy or resource expenditures.

Without a comprehensive risk analysis, projects can easily miss deadlines, overshoot the budget, suffer severe scope creep, or otherwise hinder not just the project in question but the business as a whole. The consequences can range from mild setbacks to catastrophic failures, affecting not just the project but also team morale and organizational reputation.

 

Advertisement
[widget id=”custom_html-68″]

 

Methodology

Identification:

The first step is recognizing that a rhino, for all its intriguing attributes, poses certain…ahem, “challenges” as a pet. Brainstorm and list all risks, as absurd or unlikely as they may seem.

 

Assessment:

Next, evaluate each risk based on its likelihood and potential impact. It is truly critical that you measure both sides of the equation; A potential problem that has little impact, like a few users needing help installing new software, probably doesn’t warrant a four-hour meeting and approval from the board of directors before proceeding. Conversely, an unlikely problem with severe consequences, like the credit card system going down on Black Friday, absolutely needs mitigation before proceeding. This is where quantitative and qualitative analysis techniques come into play, understanding the nuance of each risk.

 

Mitigation Strategies:

Finally, develop strategies to manage the risks that warrant attention before proceeding. This could involve anything from contingency planning to risk transfer mechanisms, all aimed at reducing the likelihood of risks or minimizing their impact should they materialize. In the worst case, at least assign a risk owner to keep an eye on a potential risk so nothing sneaks by you.

 

Conclusion:

The discipline of risk analysis in project management is about foresight and preparation. Balance your desire for a pet against the wreckage that overgrown unicorn can bring to your life. Equal parts caution and courage, pragmatism and progress, and dreams and dependability. By thoroughly analyzing risks, your projects are more likely to succeed, and you might even be able to sleep better.

Risk analysis is not just a task; it’s a mindset, a culture, and a practice that distinguishes successful projects from pet rhinos.