All about Analysis

Your question should be about a problem that many projects face. For example:

• "When a project has very little money, what is the best way to find team members?"
• "How to measure the impact and get feedback to improve the product for the real needs?"
• "Which method can handle most common scenarios for starting stage of a project finding its position in the environment?"

Write down your question clearly. This becomes your target. Everything you do next serves this target.

Go into the knowledge base and search for cases related to your question. If your question is about finding team members with low budget, search for cases where this happened. If your question is about best method for a specific stage of projects, search for analysis articles see if this has been researched before and extend it.

You will need at least two cases to make a comparison. Three or four cases give you stronger evidence.

You can also focus in a specific stage and reveal the mechanism of a method that worked or did not work for a specific situation.

Before you invest time in writing, check if someone else has already written about this exact question.

If you find an article that fully answers your question with clear evidence and solid reasoning, you can try to extend it with more evidence, or challenge it with other evidence and explore mechanism behind this contradiction to set ground for future research to find better method.

If you find an article that partially answers your question but leaves gaps, this is your opportunity. Your new article can fill those gaps. For example, perhaps an old article compared how two projects gathered resources, but it only looked at projects in cities. Your new article could compare how projects gathered resources in rural areas, or in times of crisis. This adds knowledge that was missing before.

If you find no existing article about your question, you have found a real need. Write the article.

Remember that a project has stages: Starting Point, Understanding the Problem, Getting Things Going, Gathering Resources and Building a Team, Working on the Project, Delivery, Outreach, Sustainability, and Impact.

You do not need to analyze all ten stages in one article. Choose one stage that directly connect to your question. Or if you are looking at transition between stages, choose two stages.

If your question is "When a project has very little money, what is the best way to find team members?" then you focus on the Building a Team stage. You do not need to write deeply about Delivery or Sustainability unless they directly matter to your answer.

If your question is "How do projects maintain momentum when conditions suddenly change?" then you might focus on Working on the Project and Sustainability stages, because momentum and continuity live in those stages.

Write down which stages you will analyze. This keeps your article focused and prevents it from becoming too long and scattered.

Your analysis will show readers why certain decisions worked in certain conditions, and how they might apply similar thinking to their own situations.

Start by laying out what you found when you compared your cases side by side.

Present the decisions you collected from each case. Show them in a way that makes comparison easy. You might write: "In Case CASE-LLE-2025-002, when the team had limited budget, they chose to recruit volunteers from the local community. In Case CASE-LLE-2025-004, when the team also had limited budget, they chose to hire one experienced person and train new members themselves. Both approaches succeeded, but they worked differently."

At this stage, do not explain why yet. Just show what happened. Let your reader see the pattern emerging—that different conditions led to different choices, or that similar choices produced different results.

Reference each case by its ID clearly so your reader knows exactly which cases you are discussing and can look them up if they want more details.

Dig deeper. For each decision, explain the cause-and-effect—the invisible machinery that made it work or fail.

Question: What was the hidden reason this decision produced this result?

For example, if a team with limited budget chose to recruit volunteers and succeeded, do not just say "volunteers were cheaper." Explain the actual mechanism: "Volunteers were cheaper because the organization did not pay them wages. But more importantly, volunteers came from the local community, so they already understood the local context and did not need training on community needs. This saved both money and time on a stage where the team was already stretched thin."

Show the cause-and-effect chain. Start with the condition. Show how it created a constraint. Explain how the action addressed that constraint. Show what result followed. Make the reader understand not just what happened, but why the physics of the situation made that outcome likely.

Use evidence from cases to support each step of your explanation. Point to specific details: "The team in Case CASE-LLE-2025-005 spent three weeks gathering community input before recruiting volunteers. This upfront investment meant volunteers understood the project goals immediately, reducing misalignment later."

Identify the conditions that made a way of doing something work.

Question: Would this work in every situation, or only under certain conditions?

Write clearly: "This approach works when [these conditions are true]. It may not work when [these conditions are different]."

For example: "Recruiting volunteers from the local community works when the organization has existing trust in the community and when the project timeline allows for a longer onboarding process. It may not work when the community is unfamiliar with the organization or when the project must start immediately."

Be specific about conditions. Do not say vague things like "it depends." Name the exact conditions: budget size, timeline length, team experience level, user literacy level, geographic location, existing relationships, urgency of the problem, and so on.

This specificity is what makes your analysis transferable. A reader facing a similar condition can recognize themselves in your description and apply your lessons.

When the information in the knowledge base cannot support you on the research, feel free to reach out to project teams or us asking for answers, collaborating in finding the real answer with evidence.

Have multiple cases and look at the same stage of the project that was trying to achieve the same objective. Show how different conditions led to different choices, or how similar choices worked differently under different conditions.

Write: "In Case CASE-LLE-2025-003, the team with a six-month timeline chose to research the market thoroughly before building anything. In Case CASE-LLE-2025-005, the team with a two-week deadline skipped market research and built a prototype first, then tested it with users. The six-month timeline allowed for deeper research, which prevented mistakes later. The two-week deadline forced fast learning through doing. Both succeeded, but in different ways and under different conditions."

This comparison reveals trade-offs. It shows your reader that there is no single "best" way—only "best for these conditions."

You may find that certain methods work well regardless of condition. These are robust patterns worth highlighting.

For example, if you compare five cases about building a team, and all five cases succeeded when the leader met regularly with team members to discuss challenges, you have found a robust pattern. Write: "Across all cases we examined, regular communication between leader and team members emerged as essential. This worked whether the team was paid staff or volunteers, whether the project was two weeks or two years, whether it was in urban or rural areas. The mechanism is straightforward: problems surface faster when communication is frequent, allowing the team to respond quickly."

Robust patterns are especially valuable because your reader can apply them with confidence across many different situations.

If you discovered some cases contradicted each other, or noticed cases that disagree with some analysis articles, do not hide this. Show it clearly and suggest how can we explain why.

Write: "Cases CASE-LLE-2025-005 and CASE-LLE-2025-006 took the same approaches to user engagement, however one succeeded and the other failed. The case record did not provide evidence to explain... After interview with the project team we discovered that..."

For evidence disagrees on an analysis article, write: "Case CASE-LLE-2025-005 followed approach proposed by LLE-2025-003 about user engagement, however it failed to benefit users. We discovered that..."

For cases that disagree with your analysis, write: "Case CASE-LLE-2025-005 shared same method with the analysis but presented a different result. We do encourage contributors to reveal the mechanism behind this fact and write an improved analysis standing on our shoulder."

This kind of analysis—where cases disagree—is especially valuable. It teaches the reader to think carefully about their specific context instead of applying one rule blindly.