Just over a year and a half ago, I hit a point in my career where I felt a change was necessary. What was once enjoyable became a chore, since I was not learning and innovating enough. And as a software professional, being in such state for a prolonged period of time is a death knell for our careers. We either keep moving forward or become obsolete.
After spending several years in the same role, its easy to get into a comfort zone where many things become automatic. With comfort come feelings of security and, if we are not careful, complacency. So, if security is one of human basic needs, then how do we achieve self-actualization in a position with limited, if any, possibility of growth?
Back to Cruising
Last year, I moved on and accepted a software development position with a medium-sized company in a challenging and innovative field. Now, I feel like I am back on an upwards learning curve. Leaving my consulting gig of 8 years and venturing out of my bubble was not easy, but now seems like an obvious and necessary step in personal development.
While making this career change last year, I accepted several basic truths, or, at least, what I consider now lessons in common sense. Accepted is the key term, because these truths are what I had always known, but perhaps not always followed. Measuring progress, proactively going out to industry events and meeting new people, and taking charge of my situation allowed me to breakthrough and make the necessary move in my career.
Truth 1: Progress is Tangible
And, as such, it is always measurable. Promotions aside, if we are not getting new responsibilities or learning new things over time, then, perhaps, a change is required. To track progress, keeping a simple To Do - Doing - Done list of my daily tasks allows me to focus on important things.
Every several months, I evaluate what was achieved and what progress was made. If I cannot see progress, then none exists, and some corrective action is required. Thus, maintaining periodic self-evaluations and following up on them helps to avoid rut for prolonged periods of time.
Truth 2: To Overcome Fear, Step Out of the Cave
Comfort and security are some of the basic human needs. After performing the same role for a significant amount of time, its easy to get into a comfortable bubble and out of touch with the real world. Who knows what three-headed monsters lay beyond the Pillars of Hercules.
Luckily, we don’t have to slay Geryon in order to get his cattle. Hackathons, conferences, and networking events are organized in big cities almost weekly. Nothing breaks routine and deadlock like meeting new people and listening to their ideas and fresh points of view. Likely, the people at these events are just as eager to meet us. Their viewpoints and feedback might kickstart our sidelined project or even present an unexpected opportunity. Going to a few of these occasions helped me commit to the necessary career change and led to an exciting project.
Truth 3: Breakthroughs Are Made, Not Given
One of the biggest fallacies I discovered in my youth is the perceived notion that any hard work will be rewarded. When I was twenty, I lived on my own and did jobs such as demolition and concrete removal to pay bills. If you want to know what its like to feel exhausted, try swinging a 10 pound hammer at the wall for a few hours.. ..Do it for a day, and you might make a hundred bucks. Not sure if that is an appropriate reward for inevitably wearing out your joints by age of thirty.
And yet, I think demolition was also the easiest job I ever had. What’s hard is to develop a sledgehammer of mind that breaks through perceived glass ceilings and allows us to reap the social reward that comes with building a successful career and business. Going out and getting customers is hard. Satisfying them is even harder. Constantly improving at what we do is hard. Producing more than we take back is harder still. Initiating meaningful change that impacts our whole lifestyle is often the hardest…
And yet, I think that kind of hard is what gets rewarded. I am still working on it. Ask me again in a decade.
Our app needs to send notifications to customers’ mobiles, but we don’t have much time. Fortunately, each mobile carrier provides email-to-text service for clients having a data package.
Thus, the easiest way to send an SMS message to a cell phone with a data plan would be to compose an email message and send it to the provided address.
Each carrier provides an email-to-text service in the format email@example.com. All we need to do is to compose an email message containing our text and send it to that email address.
Most of the carriers in Canada are listed below:
Bell/President’s Choice/Solo: <phonenumber>@txt.bellmobility.ca or <phonenumber>@txt.bell.ca
Virgin Mobile Canada: <phonenumber>@vmobile.ca
So how can we determine the carrier?
We can’t. In this solution, we simply send an email to ourselves while BCCing all the carriers. Only the appropriate carrier which has the recipient’s phone number will deliver the message.
Of course! In the example below, we use GMail’s SMTP service and .NET SmtpClient to send an email message.
In the last post, we wondered whether a small business or a consultant with limited resources and immature processes could compete with large enterprises having greater resources and
well-defined processes for large projects. Unsurprisingly, a small business could use strategies derived from its greatest strengths such as niche expertise, faster decision making, and
flexibility. Oftentimes, these intrinsic advantages allow small businesses to achieve more with less while maintaining greater intimacy with external stakeholders than larger companies.
Almost always, a consultant’s prowess would be the deciding factor for their success. In order to be successful, a small business or a consultant usually offers expertise in a specific
field where their experience and knowledge gives them a distinct advantage over their competitors. For example, the company I am currently with can deliver new versions of feature-rich pharmacy management product in short
iterations because it is led by a 30 year industry professional who has unparalleled expertise in delivering Pharmanet software in British Columbia. Moreover, we are supported by pharmacists who advise
us and provide their industry-specific perspective.
As another example, many large Electronic Medical Records projects are successfully completed by small healthcare professional-driven businesses employing expert analysts with many years of experience
in HL7 and medical records. In EMR projects, external stakeholders are often other healthcare professionals. Thus, having an industry expert at the helm enhances that company’s credibility and
allows the business find better solutions for that industry’s knowledge domain-specific problems.
Flexibility and faster decision making
In large companies, especially with a strong functional organization, a project manager is often limited in how much they are able to do. Additional resources are negotiated with functional managers,
and, oftentimes, the project lead does not have control over the project budget. Decisions, such as important change requests that affect scope and budget, are often beyond project manager’s
control, thus slowing and predetermining the responses to these changes.
On the other hand, a consultant usually has full control over their small business resources and can offer options to external stakeholders which are sometimes not possible in a large business. For instance,
a project lead in control of their company can allow their customer to increase scope while increasing project budget in an execution phase of the project. While traditionally, allowing scope creep is a
bad practice, in certain cases the scope changes are inevitable, especially when driven by external factors.
For example, if the aforementioned consultant is executing a project which delivers software that must pass government compliance testing, then a major change in compliance requirements could
involve a significant re-make of software features and increased scope. In such case, an expert self-employed project lead could relatively quickly evaluate these changes and make an appropriate
decision without having to wait for an approval from senior management, while enhancing their relationship with the customer. If Titanic is a yacht rather than a cruiseship, it could easily change
course and avoid the iceberg.
Finally, in the previous article, I implied that larger projects are done by larger teams. This is not always true. Quite often, a large project can be achieved with a relatively small team,
given that the team consists of industry experts. Businesses employing smaller, expert-based teams also have an advantage because less communication channels exist between team members. Less channels means simpler and more complete
control of all project communication. Smaller size of the team also helps the integrity of the original message and reduces the risk of “broken telephone”. Thus, the smaller team implies simpler and
more flexible communication planning.
Process aids expertise
So, can we conclude that a self-employed consultant can compete with a large business for a large project? The answer is a frustrating maybe. Situationally, if the project is fully within the domain
knowledge of that consultant, then their chances of success are significantly higher. On the other hand, larger projects involving several knowledge domains are probably better handled by larger
organizations with available resources in every necessary area of expertise.
In any case, larger projects require significant project management knowledge, regardless of the business size. This knowledge allows a project manager to plan their projects better and mitigate risk.
For example, I mentioned above how a small business can better react to changing government compliance requirements during the execution phase of a project. However, this advantage is nullified by
better planning. Changing government requirements is a risk which can be foreseen by an experienced project leader. While planning a project, the expert project manager would establish a
contingency budget reserve to deal with such changes, thus eliminating the need for improvisation on the fly. Thus, even a small business should strive to increase their process knowledge if they
want to grow and take on big projects.
Oftentimes, smaller businesses using extremely “agile” approaches to projects are focused on people and product, but tend to create and use basic processes as they go along. For instance, the planning phase of a small
software project could be as simple as sitting down with the customer and writing some user stories, and execution phase would then be giving those user stories to developers to code. The control would
consist of showing the customer intermediate releases hoping that the programmers hit the mark. Thus, a consultant could successfully complete a smaller project using this simple process while
relying on their subject matter expertise and heroics, as often happens in real life. I admit, many times I went straight to coding after meeting with a customer and was quite successful doing that on
multiple projects in the past.
Surprisingly or not, such approach is often advantageous to a customer, since this process is actually tailored to the customer’s needs. The customer is continuously involved in the project planning
and control, allowing the project leader to judge customer satisfaction and make adjustments on the fly. The customer is also able to make suggestions and see the project deliverables taking shape,
thus eliminating negative surprises.
Moreover, by skipping managerial deliverables, such as work breakdown structure or responsibility assignment matrix, altogether a in small project, a project lead could oftentimes increase efficiency
by reducing management effort. This is especially useful if the project lead participates in the development herself. If the consultant is able to run the project in their head and has a highly
experienced development team who know their roles, focusing on coding the project deliverables as soon as possible could be a viable and sometimes more efficient approach than traditional project
management practice to completing smaller projects.
However, a project-oriented small business eventually wants to grow and be able to handle larger projects. This raises several questions. Is it viable for those agile small businesses to successfully
deliver larger projects with more stakeholders involved while using ad hoc planning processes? Is it possible for a consultant and a project lead to remain “hands on”? What are the strategies a small
business could use to compete for large project contracts with bigger enterprises?
Managing project stakeholders
A small project could have a single external customer who is also a project sponsor. Reporting the project progress in that case is easy, and could be as simple as sending out regular emails. This
kind of reporting does not require much planning, and could be easily handled ad hoc.
But what if we increase the size of the project to where it draws significant organizational resources and has interest from several people? Suddenly, besides updating a
project sponsor, a project manager has to figure out how to manage various people’s expectations and communication preferences, and negotiate resources with functional managers. Besides, how do you handle
negative stakeholders, or people who are not interested in the success of your project, but who might have the power to kill it? Thus, managing stakeholders becomes an essential part of planning
Adding team members
A project manager could fairly easily track three people working on a two months $50K project through regular communication with each team member. Three communication channels
lead to the project manager (one to each team member). However, each of the team members also communicates with one another, increasing the number of total communication
channels to six (three within a team, three with a project manager). Still, the total amount of communication that could pass through these channels is manageable and might not require any process
to control it.
Let’s now look at what happens when a project manager has to communicate to six team members instead. Besides six channels leading to the project manager,
there are 15 other channels between team members, bringing the total to 21. Thus, doubling the size of the team resulted in more than tripling the amount of communication channels through which more
than triple amount of information could pass.
As we can see, the amount of potential information passed through team communications grows exponentially with team size. After a certain point, a project manager simply would not have enough time
during the day to control progress of the project through ad hoc communication. Thus, the project manager needs to plan communication strategy within a team ahead of time, and the planning
process becomes increasingly more important with a larger team size.
Controlling changes and scope
Increased number of stakeholders also requires a project leader to plan change control. With a single stakeholder-customer, all change requests would come from one source and could be dealt with
immediately by the project lead. On the other hand, with multiple stakeholders, change request will come from different sources and often be in conflict with one another. Thus, a decision-making
committee is often required consisting of project stakeholders and team members to approve or reject changes. Planning and communicating with such change control board further adds to the project lead’s
Besides the potential scope creep from change requests, the greater size of the development team could further add to unnecessary scope, since many developers love to gold plate. In software development,
gold plating involves programming software features which are not a part of the official deliverables, but something a developer perceives a customer would like. Adding these unnecessary features
increases project effort by time taken to develop these features and project risk by introducing greater number of potential errors.
This need to pay additional attention to controlling scope in a larger project leads to more time spent performing project management activities such as scope definition and control. A project lead
would create documents such Work Breakdown Structures which allows them to break down project scope into work packages and assign those to team members. Furthermore, a control process would be
implemented to ensure that all development works adheres to requirements. For example, the project lead might have to perform regular variance analysis of work products which could involve periodic
technical inspection of the software. These tasks put further emphasis on project management.
Tracking time and cost
In small software projects, maintaining time and cost could be as simple as counting completed user stories alone versus time taken, thus giving us a rough estimate of the progress.
Moreover, if a project lead participates in the development, they could always ballpark the progress of the manageable 1000 lines-of-code software directly from the code itself. Therefore,
the project lead often relies on their technical knowledge to manage time and cost baselines.
Larger projects have more features, increasing both time and cost commitment. More tasks means more interdependencies and one late work package could potentially affect more consecutive work packages,
increasing the risk of cost overruns and schedule slippage. To avoid schedule or cost disaster, a project lead would then perform regular earned value calculations to see if the project is on track.
Moreover, in some cases to avoid missing important deadlines, the project lead would be required to compress the schedule which involves familiarity with techniques such as crashing or fast-tracking.
Crashing involves adding resources, while fast-tracking means scheduling various activities to run simultaneously instead of sequentially. After all, can’t nine women give a birth to a baby in one month?
Jokes aside, to maintain time and cost baselines in large projects, project management knowledge and experience plays a far more significant role than technical knowledge.
When thinking about risk, an inexperienced consultant might think something like can I fulfill the contract terms reasonably well?, and given self-affirmation, risk planning would stop right there.
Come to think about it, this reminds me of a web project I did a long time ago. Back then, I never thought about risk and charged head on to execute projects as fast a possible.
While executing the project, I had a programmer working on some back-end stuff with live data. Guess what, during one of the all-nighters at crunch time, he ran truncate queries on some crucial tables
and had no backup to restore the lost data. The client was obviously furious, and I was lucky not to lose them right there. Have I brainstormed risks, I would have probably planned to do regular backups.
In any case, its obvious that large projects involve many more risks such as accidentally wiping customer data than smaller ones due to the sheer number of activities performed on the projects. Simple
example, you are working from an office to meet a critical deadline for a work package going out the next morning. Your power goes out. You improvise and take your stuff and go do it at home or at
a coffee shop. Now, imagine you have a large project where you have subcontractors working in three different cities and one of them gets hit by a storm. Do you send
them to a coffee shop as well? Are you sure about that? If not, then brainstorming risks and coming up with mitigation strategies becomes critical to success of large projects.
Planning before doing
As we can see, a larger project involves greater focus on planning and controlling processes. Once a project is above a certain size, a project lead cannot coherently proceed ad hoc without exponentially
increasing their risk of failure. Moreover, in a larger project, a project management role becomes more defined simply due to the necessity to pay more attention to planning and control processes.
After a certain point, a consultant cannot be both a project manager and a developer because they simply do not have enough hours in a day to do both.
So how then can a small business or a consultant with limited resources and immature ad hoc processes compete with large enterprises with greater resources and well-defined processes for these large
projects? We will consider this question in the next post.