The document discusses factors leading to the success and failure of development projects, highlighting the role of business analysts (BAs) in managing requirements and changes. It emphasizes the importance of effective communication, good leadership, and iterative development practices to adapt to evolving project needs. Additionally, it advocates for prioritizing requirements based on value and risk, and embracing agile methodologies as a means to manage changes effectively.

1. Why Development Projects Fail?
The Smarter Everyday project is owned and operated by CTE Solutions Inc.
Jean-Francois Bilodeau
jf@ctesolutions.com

2. About J-F
●
20+ years of professional experience
●
Certified in Java, Delphi & C#
●
Practical BA and project management
experience

3. Overview
●
Let's talk about:
–
–
–
–
–
Why project fail and succeed
Activities that BAs should do
Intergrating BA with the development project
Dealing with changes
Testing

4. Caveat!
●
This is a descriptive presentation
–
●
not prescriptive
No magic potion or silver bullets

5. Why Project Fail?
●
Is it because of:
–
Poor leadership?
–
Poor requirement?
–
Lack of technical skill?
–
Poor communication?
–
Client changing their minds?
–
Changes in business?
–
Changes in technology?
●
List is not comprehensive
●
First four are internal and can be controlled
●
Last three are external and must be managed

6. Let's flip that around...

7. Why Project Succeed?
●
Is it because of:
–
–
Good requirements?
–
Good technical skills?
–
Good communication?
–
●
Good leadership?
Managing changes?
'Good enough' is good enough

8. What can a BA do about it?
●
A BA plays a leadership position (yes, really!)
●
BA is responsible for requirements
●
Technical skills may not be necessary for a BA, but
are handy
●
BA is all about communication
●
BA must be responsive to changes

9. A BA by any other name...
●
The role of a BA can be synthetized
into two distinct responsibilities:
–
–
A BA is responsible to ellicit and
understand requirements
A BA is responsible to communicate and
validate implementation of requirements

10. “But wait! That's not how we do things!!?!”
●
Yes, I know
–
Every development team is unique
–
Every development endeavour is also unique
●
Are you a BA by name or by function?
●
What is under your control or influence?
●
What is outside your control or influence?
●
Write it down!

11. My BA Control Sheet
What can I control
I can start by creating such a
table...
What can I not control

12. How can I help my project succeed?
●
Know the difference between poor, good and great requirements
–
Poor is of little to no value to the development team
–
Good provide value to the development team
–
Great provice immediate and measurable value to the development team
●
A 300 page requirement binder does not equate great requirement
●
Good enough is often synonimous with great

13. How can I help my project succeed? ../2
●
Prioritize!
–
●
Do you know what your client considers important about
the endeavour?
–
●
Spend effort on high-value and high-risk requirements before
low-value or low-risk requirements
Is it in writing?
Do you understand what are the risks?
–
If not, ask!

14. How can I help my project succeed? ../3
●
Requirements should not be locked
away
–
–
How easy is it for your development team
to access the requirements?
How early will they have access to the
requirements?

15. So, to succeed:
●
The BA needs to create great requirements!
●
Easier said than done...
–
How do I know my requirements are correct?
–
How do I deal with changes?
–
How can I ensure that the client is getting ROI?

16. Does this look familiar?

17. The Waterfall Model
●
●
●
●
●
What's wrong with this picture?
How can we assume that requirements are correct from
the very get-go?
Any flaws in our requirements will trickle down
Flaws might only be discovered late into the testing
phase
Sounds familiar?

18. The (unfortunate) origin of the Waterfall Model
●
Popularized by the paper ―Managing the
Development of Large Software System‖
●
Published in 1970 by Wiston W. Royce
●
Never used the term Waterfall
●
Argued against the waterfall model

19. What Wiston Meant

20. In other words...
●
●
●
Software are not built...they are 'grown'
It is dangerous to assume that
requirements can gathered and be correct
in a single pass
It is dangerous to assume that testing
needs to be performed in a single pass

21. Grown...Not Built
●
Houses are built. Roads are built. Bridges are built
●
Software is grown
●
No two house or road or bridge can be build the same
–
–
●
Different terrain, material, etc...
–
●
Designs may be shared
Once a bridge is build, it cannot be copy-pasted
Developing software is more akin to designing a house than building a house, road
or bridge
Once software is written, it can be copied and pasted

22. Grown...Not Build ../2
●
The BA plays the role of the architect
–
●
Just like architectural drawings gives a sense of the final
product The requirements paint a picture of the finished
software
–
●
(Not that of the technical architect!)
The requirements are not the finished product!
Until the product is complete, it is difficult—if not
impossible—to fully test the requirements

23. Would you buy a car if...
●
●
The dealer got you to fill out a questionaire and
choose the vehicle for you?
The dealer gave you only rough drawing of the
vehicle?
●
You had a chance to sit down in it and test drive it?
●
The same applies to software

24. How do you test requirements?
●
With working software
●
With the client
●
Early
●
Often

25. How do you test requirements?
●
Get to the 'test phase' as quickly as
possible!
●
Prioritize base on value and risk
●
Stop using the waterfall

26. Stop Using the Waterfall
●
●
―How can we develop software if we don't have
requirements??!?‖
You do not need all the requirements before you get
started
–
–
●
Not even most
Not even a lot
Work with the development team as a unified whole

27. BA and the Development Team
●
●
●
●
The BA is an integral member of the team
The BA is the 'interface' between the client and the
developer
The BA is involved from the beginning to the end
of the project
There should not be 'BA/Development Team'
dichotomy

28. Moving Beyond the Waterfall
●
It's OK to do work concurrently!

29. Modern Development Methodology
●
It's not just a good idea—is the norm
●
Commonly called 'Iterative'

30. Iterative Software Development
●
Work in Timeboxes
●
Goals defined before the start of an iteration
●
Goals are not limited to implementating features
●
Goals can include:
–
Work on requirements
–
Update/review our understanding of value/risk
–
Prepare for testing, test and report on test

31. An Iteration
End
Start
Define Goals
Iteration
Review
(Goals Achieved?)

32. Are You Doing Iterative?
●
Most development teams 'claim' to work in an Iterative fashion
–
Do your iteration have a written list of goals?
–
Are those goals developped with the team?
–
Do your timeboxes have a start and end date?
–
Do you respect the start and end of your timeboxes?
–
Were any test run during your iteration?
–
Where are your test reports?

33. Iterative Development and the BA
●
BA needs to be involved from start to finish
●
Multiple incremental deliverable
●
Client gets a chance to test-drive the product early
●
Client can provide feedback and validation early
–
But what if the client changes their mind??!?

34. Software Development and Change
●
●
●
●
How many BAs ever worked on a project that
required changes to their requirements?
How many Bas ever worked on a project that
required no changes to their requirements?
Change is not an exception—it's normal!
Remember: It is difficult, if not impossible to know
everything from the get-go

35. Dealing with Changes
●
Change is a reality in the software
development field
–
●
Otherwise, would we will have a job ;)
It's not a question of protecting against—
or resisting—changes, but to manage
changes

36. How to Deal with Changes
●
●
Agile Project Management
Developped in 2001 by 17 software
developers
●
Intergrates naturaly with iterative
●
Agile is a philosophy—not a method!

37. Agile Manifesto:
●
We are uncovering better ways of developing software by doing it and
helping others do it. Through this work we have come to value:
–
–
Customer collaboration over Contract negotiation
–
●
Working software over Comprehensive documentation
–
●
Individuals and interactions over Processes and tools
Responding to change over Following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
http://agilemanifesto.org/

38. Agile and Iterative
●
Two separate approach
but
●
●
Integrate naturally
Spread from software development into
most project management disciplines

39. Caveats!
●
Agile and Interative is not a free-for-all!
–
Requires discipline
●
Requires good leadership
●
Test, test, test

40. BA and Testing
●
The BA is not the tester
●
The BA is accountable for the testing!
●
The BA works with the test team and
ensures that they can and do the tests

41. BA and Testing ../2
●
Do you:
–
–
–
●
have a test team?
have a test plan?
have a test lab?
If not, are they on your iteration goals?

42. In summary...
●
Prioritize base on value and risk
●
It's OK for the team to work in parallel
●
It's OK to start writing code while requirements are begin
gathered
●
Change happens and it's normal. Manage it
●
It's OK Necessary to start testing as soon as possible

43. Homework
●
Write down what you can and cannot control
●
Identify what your client considers value
●
Identify risks that would put the endeavour in jeopardy
●
Write down short term goals that you need to achieve
●
Commit to a date for the above goal and review them
when that date rolls around.

44. Final Wisdom
Write a list of short-term and long-term
goals you would like to achieve as a BA
then
Take small, incremental steps to reach
those goal

45. TECHNICAL
Microsoft
VMware
Cloud Computing
IT and Cyber Security
CompTIA
Java ProgrammingLanguages
Novell
UNIX
Training with impact
MANAGEMEN BUSINESS
Change Management
TOGAF
T
Enterprise
Architecture
ITIL
COBiT
Agile and Scrum
Business Analysis
Project
Management
Communication Skills
Leadership Skills
Negotiation Skills
Problem Solving Skills
Facilitation Skills
and many more…

46. CTE Solutions Inc. - Ottawa
11 Holland Avenue, Suite 100
Ottawa, Ontario, K1Y 4S1
Tel: (613) 798-5353
Toll Free: 1 (866) 635-5353
Fax: (613) 798-5574
CTE Solutions Inc. - Toronto
77 Bloor St. West, Suite 1406
Toronto, Ontario M5S 1M2
Tel: (416) 284-2700
Toll Free: 1 (866) 635-5353
Fax: (416) 284-6797