Skip to main content

Tag: Project Management

5 New Project Management Tools You May Not Have Used Yet

Project management is a huge headache, but it’s also unavoidable,

being a key component of running any type of business you care to mention. Without projects, internal or external, you’re left in a perpetual state of winging it — and with projects that are unmanaged or poorly managed, you’re only marginally better off.

This means you need to maintain a tight grip over every aspect of each project you undertake. From the very first brief to the final sign-off, you need everything catalogued, distributed and archived accordingly. This can be done completely manually, but it’s far more work than anyone should consider taking on that way. That’s where project management tools come in.

Project management tools help you keep track of what your goals are, where resources are going, how deliverables are coming along, and how distinct teams are cooperating and collaborating. To help you keep your approach moving with the times, here are 5 such tools that you might not have tried yet:

Wrike

If you’re looking for a broad project management suite, you’ll find no shortage of viable options out there. Systems like Asana and Trello are enduringly popular, and new contenders pop up on a regular basis. Wrike is a choice that has steadily crept up in perceived viability, and stands (in its current iteration) as an exceptional option that’s certainly worth a look if you’re unfamiliar.

What makes it so useful? Well, it has reasonable pricing ($24.80 per user per month at the business tier) and provides exceptional functionality. The cloud-based interface is crisp, clean, and clear, and the onus is on comprehensive usability. It isn’t the slickest program out there, and it will likely be seen as a little complex at first, but the learning curve is worth it.

MeisterTask

Created for agile working, MeisterTask is a simpler and more colorful solution than Wrike. Its layout flexibly rearranges to suit your needs, no matter what specifically you’re trying to achieve, and if you don’t need fancy integrations, you can use it for free — indefinitely. That certainly makes it something worth considering.

If you do want those integrations, the pro tier is very affordable, so it’s unquestionably a justifiable expense. With so many project management tools offering comparable functionality, it really comes down to personal preference. What menu style do you prefer? What layout format? Experiment with new tools when you can, and you might just find a better fit.


Advertisement

Weekdone

Weekdone is all about specific objectives: for the week, for the month, for one person, for an entire team… if you’re determined to achieve particular things before particular dates, this type of intuitive format might be perfect for you. The challenge innate to more complex tools can cause headaches, but Weekdone is incredibly straightforward.

The pricing is similarly simple, scaling up the more users you need. Having 100 premium users (complete with onboarding and training in the event that you need it) will cost just $6 per person per month. There are also Android and iOS apps that offer at-a-glance graphics showing project progress — perfect for busy managers that need oversight to be optimally simple.

Fleep

You’ve inevitably heard of Slack — it’s one of the most widely-used business communication tools in the world, after all — but it isn’t the only program of its kind. Fleep was built along similar lines, but it goes about things in a slightly different way. You can think of it as a cross-platform hybrid: instead of limiting chat to specific channels, it brings together live chat and email into an interface that allows people in your operation to communicate live regarding specific emails.

It’s also open to the extent that no one needs a Fleep invitation to participate in an exchange if invited. You can simply email them about it and make them a part of the live exchange. And with the free version allowing file sharing, message history storage, and unlimited conversations, it’s a highly affordable choice.

Zapier

This might seem like an odd choice for this list, but allow me to explain its inclusion. Zapier isn’t innately a project management tool, but given that it can add so much to project management, it absolutely warrants a place on this list. Zapier is an integration tool that allows you to connect apps of all types and purposes, allowing you to get your broader operation running smoothly.

Consider this: Zapier supports integrations with every other tool I’ve listed here, and can easily get them hooked up to CRM systems like Zendesk or ecommerce platforms like Shopify Plus or WooCommerce. Integrations via Zapier frees your team from getting bogged down with admin and other repetitive labor-intensive tasks so that they can dedicate more of their time and effort on the tasks that mean more to your business’s bottom line.

Project management can always become more efficient, and this is reflected in the ever-developing software scene. Whether you’ve just dipped your toes in the ocean of digitally-enhanced project management, or you’ve been using solutions like Trello for quite some time, there’s always room to try new tools. Why not give these a shot?

Growing up Agile vs. Growing up Waterfall…. Let’s Get Real About What Matters Most!

In my classes I have been increasingly confronted with students who are trying to transition from waterfall to agile,

and more and more students who ask, “What’s waterfall?” Those who have never experienced waterfall think some of the waterfall practices they hear about are completely ridiculous, and I have to agree. Likewise, those who are new to agile and have lived a waterfall life for many years, struggle to see how agile will relieve the pain points of yesterday and today.

The common theme with both groups is that they all need to learn, and in some cases relearn, good analysis, communication, and leadership skills. They need to understand how these skills play together in the BA role to deliver great products and solutions to users and customers, ultimately getting business results.

My biggest concern about most agile transformations today, and especially with the BA role, is that we are unconsciously recreating the same problem we are trying to fix. We have been trying to fix the problem of delivering solutions that users actually want and will solve for their problem for years. We keep fumbling, creating rework, missing expectations, and creating waste in an effort to do it faster over building the right thing. Agile, for many organizations and teams, seems to be just another way to speed up the process. What differentiates agile success from agile pain is if the right agile and analysis practices are in pace to build the right thing, not just build it fast. We are all trying to get great solutions users love, fast and with high quality.

When I hear leaders say, “I want projects done faster,” I don’t think they actually mean that so literally! I have no problem confronting this and asking them about it. When I dig deeper, what leaders really want is outcomes and faster results. The way we measure projects is rarely results based, so faster projects doesn’t get results, and the disappointment ensues.   This begs the question, are we defining and measuring the right outcomes and results? Do they align with what the project is trying to achieve? It is actually agile to do so, and waterfall best practices would agree as well. It is a key part of the BA role to work with leaders and stakeholders to define outcomes and results. Outcomes and results that matter! They don’t want the project done by the end of the month; perhaps they want to start seeing users complete their tasks faster with a new solution by the end of the month. Measure what matters! BAs are the role to define the measurements that matter!

When I hear leaders say, “I want less rework and less missed requirements,” again, I don’t think they mean it as literally as we hear it. What they really want is the right requirements implemented to solve the problem or advance the user and business goals. Getting the right requirements to solve the problem, will result in less rework and less missed requirements. Are you scratching your head yet wondering if you are measuring and focused on the right things?


Advertisement

I also don’t think that leaders want “less defects.” Instead, they want satisfied users, and it’s okay if there are lots of defects with satisfied users. It’s not okay to have users with more problems and lower satisfaction because we have a few really impactful defects.

Not relevant

Relevant

Speed of project completion

Speed to results and outcomes

Missed requirements & rework

The right requirements implemented

# of Defects

Satisfied users

The issue is that teams and organizations are measuring BAs and teams on the wrong things. And waterfall and agile teams are having the same issues with this. Unless the real outcomes and results from a customer and business perspective are defined, measured, evaluated and tracked regularly, the risk of project waste and failure is high.

It seems obvious, but why is this so hard for organizations to do? The methodology or framework you choose won’t guarantee this happens and won’t guarantee results.

  • No matter if you are working in a Waterfall, Agile, Wagile, Scrumerfall, or whatever you affectionately call it, my real questions are:Are you focused on what matters?
  • Do you know the results that the project intends to deliver from a user point of view?
  • These are not output results like: How much was coded, tested, etc. or if a feature was implemented. I am talking about results that the software creates for a customer or business.

Things like:

  • Decreased the amount of time it takes for a customer to submit a claim from 3 days to 3 min.
  • Increased sales opportunities by 15% by using AI to prospect and predict potential customers.

BAs play a critical role in defining and delivering results, getting the right requirements implemented and having satisfied users. Focusing on defining the results desired, and then managing and tracking them is key!

Why Common Sense is Not Good for Software Development Teams

Recently, I had to create an account for one of my children’s school-related matters.

Once the account was created, a token to verify the email address was sent to my email address.

Emails sent to this email address are retrieved by another email provider using the old POP3 protocol. When the email with the token arrived and I clicked the link, the requesting server replied, “The supplied token is incorrect or has expired”.

I obtained a new token but it also expired, and the next one did too and so on! The time allowed to respond was set too short for this particular POP3 scenario, which meant I was stuck between clicks, and unable to continue.

I was able to overcome the problem eventually, but the point is that during software development and testing of the account creation feature, this particular scenario was somehow overlooked. The dev team may have used, common sense or the “very rare, not worthwhile” argument to avoid doing further analysis or simply, nobody thought about it.

In this case, there were no huge consequences (only a few hairs of the few I have left were pulled out), however, in a different situation, not deriving important business scenarios from requirements, user stories or features may be a very costly oversight.


Advertisement

More than common sense

Agile practitioners sometimes characterise Business Analysis (BA) as nothing more than “common sense”, thus precluding any further efforts to understand important aspects of features. i.e., a customer’s real needs, and the business context where the needs are drawn from.

We claim allegiance to “customer satisfaction”, or to “improving product’s user experience”, but do we only go as far as “common sense”? Business Analysts are actually very weary if “common sense” is proposed, particularly when it is used as a means to jump into “quick solution” mode.

More often than not, ‘common sense’ only leads to lacklustre solutions, or increased development and/or testing time due to lack of understanding. Emulating the term “technical debt” used in agile dev teams we could say lack of true business understanding generates a kind of “business debt” potentially rendering a piece of software code unsuitable.

This is why BAs are not mere “problem solvers”, but far more importantly, they are “problem understand-ers”.

A wealth of BA skills can be used to explore, analyse, and understand real needs and business context. Scenario analysis, personas, customer journeys maps, and conditions of business value are some popular ones that come to mind.

The right mindset

A colleague at work recently mentioned that while “anybody can take a photo, not everybody is a photographer”. He was quite right!

Skills and the techniques by themselves are not enough to understand something. They necessary, but they are only the “what” without a sense of “how” they can be applied.

This brings to the fore an important competency of Business Analysts, namely the “BA mindset”. The BA mindset has its foundation and focus on delivering business value from accumulated knowledge and ability, and helps determine how well you can use skills and techniques in a specific situation. Just like a professional photographer.

Agile teams not only produce software, but they must also produce “valuable” software and “value” pertains to the business domain. The business domain needs to be explored and understood if we want to deliver value in the first place. That is what BAs do!

The “analysis” task within an Agile team, no matter who performs it, beyond common sense requires business analysis techniques, and the skills and competencies of business analysts. Although these can be learnt, in order to truly build a great analysis capability within Agile teams a dedicated member of that team is best, regardless of title, role or where they sit on the development team. If not a BA, a BA can coach them!

From the Sponsor’s Desk – The Nuts for Cheese Project

“Follow your passion, be prepared to work hard and sacrifice, and, above all, don’t let anyone limit your dreams”.

– Donovan Bailey, retired Jamaican-Canadian sprinter, who once held the world record for the 100 metres.

We know that great sponsors make major change initiatives exciting and successful experiences. If we could bottle that “great sponsor” juice, what do you think we’d find in the bottle? Chances are we’d find the ingredients that are present in this month’s case, the Nuts for Cheese project.

In this post, we’ll follow the path one woman took to develop her knowledge and skills and launch and guide a company that, in just three years, is now offering its high quality products through small and large retailers across Canada.

The Situation

In her early teens, Margaret Coons’ love for animals convinced her to adopt a vegan life style. That meant eliminating everything of animal origin from her daily life, including meat, milk, eggs, wool, leather, honey, etc. To her parents’ amazement, she proceeded to learn how to prepare plant-based foods that would complement what was available and prepared in the family kitchen and replace the meat and animal products that were consumed by the other members of the family.

Margaret continued her vegan lifestyle through her secondary and post-secondary school years, graduating with a degree in English Language and Literature from Western University in London, Ontario.

After graduation, she worked as a chef in a local vegan restaurant preparing plant-based foods. In the evenings, after work, she rented the restaurant’s kitchen to experiment and learn, developing her own recipes. They would often appear on the restaurant’s menu in subsequent days, giving Margaret valuable customer feedback on her creations.

In addition to the night time experimentation, Margaret completed Rouxbe’s Plant-Based Professional Certification, appeared on London daytime television with creative vegan cooking demonstrations and offered cooking lessons and classes at local fairs. She also provided private catering and helped other culinary establishments create vegan recipes. All this while working as a chef at the vegan restaurant. But her love and her specialty was creating cashew cheeses. She started her business on a small scale, offering her products at local farmers’ markets and contributing her wares at a local vegan food bank.

In 2016, the local vegan restaurant closed its doors. Margaret had a decision to make, and she made it – to go full time and full bore with her own company, designing, making and selling cashew based cheeses. And so she launched the Nuts for Cheese project.

The Goal

Margaret’s vison for Nuts for Cheese: To be the #1 selling, high quality, great tasting vegan cheese that people love.


Advertisement

The Project

Margaret’s initial challenge on hearing about the vegan restaurant’s closure was to find a new location and hire and train staff to help her get back up and running. She located and contracted for a small 1200 square foot space, hired four staff and was back producing her cashew based cheeses in short order, serving about 25 retailers and continuing to cover local farmers’ markets.

A year later the company landed Farm Boy as a client and moved to a larger production facility to serve the orders from a growing customer base. Two more moves were required in the following years as demand continued to grow. Nuts for Cheese now operates out of a newly acquired 11,000 square foot facility. The number of staff has also grown, currently standing at 23 and counting.

Margaret admits that she became an entrepreneur by accident. With little formal business training, she had to learn on the go. She has enjoyed the guidance of mentors along the way, including her current mentor who offers expertise on the grocery business, quality control and supply chain management. As the company is self-funded, she has had to master and aggressively manage cash flow, the supply chains, hiring and management of a growing workforce, putting an organization structure in place and, of course, the facilities to house her operations.

Margaret’s recipes for her cheeses are a reflection of the dedication and precision she brings to all aspects of the company’s operations. She starts with organic cashews which are soaked in filtered water for 24 hours to create the base cashew milk. The milk is then fermented for 24 to 36 hours using yeast cultures created in house. The fermented milk is then seasoned and aged to create the company’s unique offerings including Un-Brie-Lievable, Super Blue, Chipotle Chedder, Red Rind and Smokey Artichoke and Herb. The company also creates all its own seasonings using all organic sources.

Margaret’s passion for quality is reflected in her hiring practices. To date, she has interviewed every candidate and participated in every hiring decision. Her primary hiring criteria are personality match, values match, then skills. The use of only organic products and the creation and operation of rigorous quality control practices at each stage of the supply chain simply reinforces that quality ethic. The company has applied for and is currently waiting on formal organic certification for their products.

The Results

In the three years since its launch, Nuts for Cheese has tripled revenue every year. The number of staff has grown from four people to twenty-three. It has just moved into a new 11,000 square foot production facility to supply its products to retailers across Canada, including major grocery chains. And the firm was just named one of the top 14 employers in London. Not bad for an accidental entrepreneur!

How a Great Leader Succeeded

Margaret’s journey with Nuts for Cheese is a wonderful success story, but it’s also a wonderful roadmap for managing any kind of change. The values and tenacity she brings to her job as CEO are the same qualities and attributes that make great sponsors, successful projects and wonderful experiences in any field. That includes:
1. Knowledge – Margaret built her vegan knowledge from her mid-teens on, studying, experimenting, sharing and soliciting feedback iteratively and incrementally. From her early ventures into a vegan diet, to the restaurant’s kitchen, to her after hours experimentation and creation, to her formal education, Margaret acquired the knowledge to succeed in her Nuts for Cheese adventure and openly shared that wisdom.
2. Commitment and passion – Take a look at Margaret’s goals for her company. #1 seller. High quality. Great tasting. People love it. Take a look at the recipe. All organic with quality control processes to ensure that’s the case. Seasonings and yeast cultures created in house. Take a look at who and how she hires. Personality, values, then skills. Involvement in every interview and hiring decision. Add Margaret’s regular 80 hour weeks to that mix and it’s evident that passion and commitment are drivers of the company’s success.
3. Collaboration – Perhaps more than anything, collaboration characterizes Margaret and her company. From her early years with her family, to the restaurant experience, to her engagement and work with mentors, to her relationship with her staff, customers and communities, collaboration has been the hallmark of her approach to life and business. That’s how the name for the company was developed – brainstorming with friends and colleagues.
4. Sharing core values – Margaret hires people who share the core values she wants for the company. That reinforces and builds a collegiality based on customers, quality and success. The company’s selection as a top place to work is evidence of the strength of that sharing.
5. Lessons learned – Without a business background, Margaret and her staff have acquired and shared the operational, supply chain, quality control, marketing, distribution and product development skills and insights needed to grow the company and provide their customers across Canada with tasty, quality products.

In his article The Speed Trap – When Taking Your Time (Really) Matters, Tom Peters states: “An organization is nothing more and nothing less than people (our folks) serving people (our customers and communities).” It is evident Margaret got that right. She “owns” her Nuts for Cheese project lock, stock and barrel. It’s also apparent that her staff shares her ownership. That’s the force multiplier. The whole is significantly greater than the sum of the parts. If you are a project or change manager, imagine what your projects would be like if your sponsors, key stakeholders and project staff exhibited the characteristics described above.

So here’s a suggestion: use these points to evaluate your sponsors, key stakeholders and project staff. If there are gaps and deficiencies, include activities in your project plans to build collective capabilities and close the gaps. Also remember, use Project Pre-Check’s three building blocks covering the key stakeholder group, the decision management process and the Decision Framework (including key stakeholder assessments) right up front so you don’t overlook these key success factors.

Finally, thanks to everyone who has willingly shared their experiences for presentation on this blog. Everyone benefits. First-time contributors get a copy of one of my books. Readers get insights they can apply to their own unique circumstances. So, if you have a project experience, good, bad and everything in between, send me the details and we’ll chat. I’ll write it up and, when you’re happy with the results, Project Times will post it so others can learn from your experiences.

Poor requirements can triple the length of the project

Requirements are the lifeblood of the project. Period.

And bad requirements or missing requirements can triple the length of the project. Worse, they can kill a project altogether due to time or budget (or both) issues.

I just had a simple home project for my wife go south because I failed to get the requirements fully defined before starting. I thought I had everything right, but I made some assumptions without asking certain questions. Keep in mind she is my very organized wife who hates it when I ask too many questions before starting a project for her. But our project customers have a potential to be problematic, stubborn, demanding or even uncooperative, right?

Next project today I got detailed requirements and then clarified and asked a couple of questions. We were definitely on the same page. When the project was over an hour later – complete to the original specs (I thought, anyway) and I asked if this looked ok and she said “oh heck no.” This was an example of some customers who just can’t be pleased or impressed. You may have to cut them loose if this keeps happening, but in my specific case with my wife, of course, that isn’t going to happen… you get the picture.

So, what can we do to ensure this doesn’t happen / and to keep my wife from getting mad at me on my next home project? We can focus on these 4 things…

Schedule enough planning time.

One of the biggest reasons there are disconnects between what the customer wants, the requirements that get documented, and the solution your team builds is lack of enough planning time. Requirements are so critical – you really can’t spend too much time on them as long as it is reasonable for the project. But cutting corners on the requirements definition phase is a definite no-no. There is no specific yardstick on how long to spend planning and documenting requirements. I wish I could give you an exact formula and if I could I would probably be a millionaire. Initially, for a good-sized tech project that is going to last 6 months or more, I would put at least 2-3 weeks into the schedule with 3-4 dedicated meetings and several assigned subtasks. Understand that the window for documenting requirements may expand or contract – it will be hard to predict but you must document detailed requirements thoroughly and as accurately as possible. Period.

Ask more questions even if it may seem like too many.

The bottom line is this – we need to avoid bad requirements and mis-understood requirements at almost all costs. Extend the requirements definition phase out if necessary – even if it injures the project budget and timeline early on. That is far better than extremely costly rework later in the project that might also serve to triple the length of the project as suggested by this article’s title. Take more time to analyze, define and document requirements. Ask more questions – lots of questions – of the customer project sponsor, the subject matter experts (SMEs), the ultimate end users – anyone and everyone on the customer side that knows what they want and need from the solution. Complete requirements that are complex and detailed set the stage for successful user acceptance testing (UAT) as well as a well-designed end solution that will meet the users’ needs and bring a successful conclusion to the project engagement.


Advertisement

Repeat the requirements individually as they are documented.

This may seem either obvious or overly mundane – depending on the individual or personality type. And you can argue till your out of breath against it but if it saves even a few hours of re-work by 2 or 3 project team members that could be $10,000 of project budget saved just be clarifying a requirement out loud. It goes along with my stance of following up after every meeting with notes from the meeting to make sure everyone is on the same page. We all have the potential to hear things and interpret things differently and we all go into each communication incident with some pre-conceived notions and are therefore bound to come out the other side with some varying understandings. Repeat requirements – get common understanding. It’s logical… common sense. Most PM best practices are that logical. It’s not rocket science.

Review the full set of requirements before beginning any project work or next phase.

Once all the requirements for the effort are detailed and complete, the business analyst should schedule a 3-5-hour session (longer, if necessary – depends on the complexity of the project and the size of the requirements document you’ve assembled) to review and discuss the full set of connected requirements. Do these now make sense and fit together right to form the intended solution? I do this and have never regretted it. There has never been a project where at least five or ten key requirements weren’t missing some detail or omitted completely. On multi-million-dollar projects that may translate into a savings of $100,000 or more of re-work and lost schedule fixing what was wrong or missing. Again, this session is just good common sense… good communication and good management. Planning and documenting is critical, so is follow-up to ensure common understanding and completeness.

Summary / call for input

The bottom line is this – whether it’s a big 18-month tech project for a client you’ve known for two weeks or a two-hour Saturday morning project for your wide who you’ve known for almost 36 years, clarity and completeness in project requirements is critical. Anything less can leave you with lost revenue, profitability and time or on the home front… well that’s going to vary a bit with each relationship… but it could prove to be problematic for a couple days.

Readers – what are your thoughts? Have you had projects start with less than complete rand clarified and fully understood requirements? How badly has it affected your project revenue, profitability and timeline? Please share and discuss.