This is a Project Based Training programme that I developed and implemented in 2016. It is called "The Valhalla Project" and it tests how well the practices of SDLC and systems engineering can be applied in a more general management scenario.

1. THE VALHALLA PROJECT
Dhaval M. Anjaria

2. About me
● Former small time freelance developer.
● Worked on some small projects for individuals.
● Mostly stuck to C# with .NET 2.0 / 3.5 and basic IT support.
● No corporate experience.
● Some hiccups: Qt Project went bust, learned Android but no projects,
major PHP based e-commerce thing didn’t happen, etc.
● However, wide range of skills in systems administration and
development because of time.
● Worked on several different things in Cognizance 2015.

3. I like making Pasta.
● I like making “Aglio Olio”, which is Pasta in Garlic and Olive oil.
● I like it spicy, no cheese, crunchy with walnuts and cashews and I don’t
mind if it’s a little roasted.
● My sister on the other hand likes very different kind of Pasta. She likes
smooth, creamy, cheesy pasta.
● The pasta I make simply for myself, is very different from what I make
for other people, especially if we have guests.
● Similarly, software engineers are not paid to turn caffeine into code.
They are paid to make software that works for the customer.

4. Cognizance is the Pasta, Valhalla is how you
make it

5. ● Ritu said it best, “We’re not getting anything but mere certificates for all
the work we are doing”, which is true for most people.
● Cognizance 2015 was very productive (for myself).
● Learned PHP, practiced HTML5/CSS3/JS and some Photoshop.Got
projects in Feb 2016 and August 2016.
● Worked on setting up OpenStack cluster, which failed spectacularly.
● Valhalla isn’t about solving a problem, as much as exploiting an
opportunity.
● It uses Cognizance as an opportunity to learn and grow. The idea is to
implement the theory we learned in college and in IT.
The Problem and the Opportunity

6. The Valhalla Project
● “Valhalla” comes from old Norse mythology. The idea is that to go to
heaven, you must die fighting.
● Created to manage and conduct Cognizance.
● Meta-project; which means that it is a project that pertains to
conducting the Cognizance event.
● The basic idea is to apply the ideas of Software Development to
managing a tech fest.
● Exists in the form of a document. It is basically like an RFC.
● In fact, the document was supposed to conform to RFC 2119.
● Provides guidelines and rules for projects to follow.

7. Inspiration: OS and SSAD
● In Semester II, we had two very important subjects: “Operating
Systems” and “Structured Systems Analysis and Design”
● OS was about how an entire Operating System (and so how large
software systems) are implemented.
● SSAD was a more classical approach to creating a systems. Introduced
the concept of “The Analyst” and “The System”.
● SSAD presented a different, much more formal and structured
approach to developing systems than what I was used to.
● Presented the SDLC as applied to entire systems.
● A lot of the ideas in the Valhalla project are taken from OS and SSAD.

8. The Primary Purpose
● The whole point of this is simple: to gain knowledge and experience.
● It uses Cognizance as a platform to try to implement the principles of
Software Engineering to the management of a tech fest.
● Cognizance is a laboratory, a crucible, to experiment with stuff that we
already know or want to learn and actually apply them in a real
scenario.
● It creates an environment that gives us problems that we won’t face in
a mock project.
● Basically, it uses the ideas of software development to conduct
Cognizance in a cost-effective and productive manner.

9. Projects and Teams
● There are two basic ideas, “Projects” and their “Teams”.
● These are split completely into two categories: Technical and Creative.
● Each category will have a respective Lead.
● Technical refers to any project that uses computers extensively, and
creative projects refer to anything else that is part of Cognizance.
● Each Project will be assigned to one Team and will fall under either
Technical Projects or Creative Projects.
● Projects can have sub-teams that are part of sub-projects, but mostly
these are very isolated from each other so as to reduce dependency.
● Structure is basically the MIS pyramid.

10. Flowchart
Project is
proposed
or
decided
Submit
Documentation
Approval
by Lead /
Valkyrie
Project
commences
Progress
reports to Lead
Presentation

11. Flow of Information
(Greater
amount of
info)
(Lesser
amount
of info)
Docs,
reports,
budgets,
etc.
Approvals,
decisions

12. Projects
● Projects are divided into two categories: Technical and Creative.
● Technical Projects are those which involve computers (primarily) and
creative projects are all the rest.
● Projects refer to a goal that needs to be achieved, and it may or may not
be towards the completion of the Cognizance event.
● Projects must also be isolated and mostly independent from each other.
This is somewhat similar to concepts in Process Management and DBMS,
(i.e. the ACID principles).
● The reason for this is so that the failure of one project does not affect
any other projects.

13. Teams
● One team is assigned to one and only one project. The idea being
separation of concerns, UNIX philosophy, etc.
● They would be reasonably autonomous. This means that they would
decide which members to take, how to approach their project, what
organization they would have and who would do what.
● Recommended maximum of five members, if there are more, they
should be split into sub-teams. Sub-teams are associated with one
sub-project.
● Teams should not share members. This is to reduce dependencies.
● The Valkyrie, in Norse Mythology, were the angels of Odin that decided
the outcome of a battle. This way, the Valkyrie would decide which
project would be considered for review by the Leads.

14. Budgets and Dependencies
● Document proposes that the budgets be separate. If there is a common
budget, then a certain amount of money be set aside for both categories
of projects, and subsequently for each project.
● Teams must also justify a budget. That is to say that a proper
breakdown of where they’re spending the budget must be submitted to
the Valkyrie.
● Projects could actually depend on the completion of other projects. For
example, Snakes and Ladders technically depended on the completion
of the Dice Throw project.
● Under Valhalla, it is recommended that if a team requires work from
another team, they should enter something of a formal agreement to do
this. It simply recommends that a process be followed and document.

15. Technical Projects
● Projects that require the use of computers extensively.
● Should use a new tool or development methodology.
● General Guidelines are:
○ Should be focused on tech.
○ Must implement a technology that the teams are mostly unfamiliar with.
○ Must have a presentation at the end.
● These projects would fall under the purview of the Technical Lead, since
they would have the responsibility for these projects.
● The technical lead is answerable (and responsible) for these projects.
This is because they would have an overview of all the projects, their
needs, deadlines, etc.

16. Technical Projects done under Valhalla.
● Dice throw by Akshat Sharma.
● Online Examination System by Kishor Trimal.
● Android platformer game by Siddhant Kumbhar
● CS by Yash Atishay and team
● FIFA by Rahul Chettiyar and team
● Arduino bot by Dishant Dubey and team.
● Raspberry pi gaming system by Arvind Thevar and team.
● Website by Dhaval Anjaria

17. Creative Projects
● May not strictly follow Valhalla. This is because since Valhalla aims to
apply the principles of Software Development, these principles may not
be fully applicable to non-technical projects.
● Deadlines should be the dates of Cognizance and no presentation is
required.
● Should not, in theory, interfere with the function of Technical projects
and vice versa. Sharing of resources and personnel is also greatly
discouraged.
● Threads and processes in OSes work this way. They have to be as
separate as possible to avoid problems (eg, Race Conditions and
Deadlocks)

18. Technical and Creative Leads
● Technical lead would be in charge of all technical projects and the
Creative Lead for creative projects.
● Each lead would have authority to decide which projects may or may
not be approved. This is because they would be responsible for all the
projects under their purview and communication to the rest of the
Valkyrie.
● This is so that the teams can focus on the project, the Valkyrie can
focus on other things and in this way, we reduce dependencies and the
workload on all of these parties.

19. Role of the Technical Lead
● Technical Support.
● Negotiations of Budgets
● Setting deadlines.
● Communicating and coordinating requirements, budgets, etc. for all the
projects.
● Making sure documentation is in order.
● Setting a failure state.
● Coordinating presentations and deciding what should be covered in
each presentation.

20. Role of the Creative Lead.
● Providing resources, time, etc. to each creative team.
● Managing between various teams and taking care of what work each
team is doing.
● Coordinating a budget and keeping track of everything.
● Planning and organizing with each team with regards to how they will
work together.
● Any sort of support that a team would require from other projects or
the Faculty, etc.

22. General guidelines for both types of Projects
● Experimentation
○ Required to use new or unfamiliar technology, or some form of management (for
creative projects).
● Documentation
○ Projects should submit initial documentation describing the project.
○ This includes Requirements, Feasibility review, Budget estimate, etc.
● Independence
○ Projects should be reasonably independent of each other.
○ It should also be reasonably able to meet its goals without dependence on other
projects.
● Cost-effectiveness

23. General Guidelines (contd.)
● Failure
○ Projects must have the option to fail.
○ Failure may mean unable to reach a deadline or coming across an issue that cannot be
resolved or not being able to reach the goals in the requirements document.
○ This is why “Valhalla” was chosen. The idea is, even if a project fails, the experience
and knowledge gained from it would be invaluable.
○ This is why independence of projects and teams is crucial.
○ For example, when the project I had in February didn’t pan out, it wasn’t costly to me
because I at least learned the Bootstrap framework for it.

24. Specific guidelines for technical projects
● Use of Technology
○ Technical projects must use a technology of methodology or something unfamiliar to at
least one team member.
○ Eg, it is recommended that the Technical Project follow at least the Waterfall approach
● Budget and Expenses
○ Budget should be around 1000 rupees.
○ This is based on past experience and other factors.
● Documentation
○ Most important part of all of this.
○ Projects must submit an initial proposal to the technical lead. Once it is approved, they
must submit a more detailed SRS.

25. Specific guidelines for technical projects
(contd.)
● Documentation (contd.)
○ Projects must also submit progress report so that there is a written record of where
each project is in their development.
○ Along with this, a written list of team members should be submitted to the TL.
● Deadlines
○ Deadlines must be decided by the TL by coordinating with other teams in Valhalla /
Cognizance.
● Failure State
○ The failure state of a project may decided by several factors.
○ This could be decided by the TL, or the team members themselves. What constitutes as
a technical project failing may be determined at a later date, but this is not really
important as long as all the documentation is in order.

26. Specific Guidelines for Creative Projects
● Creative projects need not conform as strictly to these guidelines as
technical projects.
● Budget and Expenses
○ A proper budget should be submitted to the Valkyrie
● Documentation
○ It is recommended that proper documentation be maintained similar to technical
projects.
● Deadlines
○ Deadlines should be Cognizance.
● Failure state
○ May be defined by the projects themselves or the Creative Lead.
● Presentation or Workshop.
○ It is not necessary for creative projects to have a presentation or workshop.

28. Presentation and Workshop
● This is basically what Valhalla leads up to.
● Regardless of failure, all technical projects must submit a presentation
or prepare a workshop detailing what technology or principles they
have applied, what issues they faced, etc.
● The objective of these presentations would be to share the knowledge
gained by a team with others, hence meeting the primary objective of
the Valhalla project.

29. Lessons learned.

30. QA and Incentives
● One of the primary challenges as a Technical Lead, was that people
weren’t properly motivated to submit Documentation.
● I believe the reason for this was that at the end of the day, there wasn’t
a proper incentive for doing this.
● In fact, no QA measures or Incentives or any form of control was
applied.
● The reason for this was to give people as much freedom as they need
so long as the do something constructive.
● However, how well this worked out is another matter.

31. Time and Complexity of the Valhalla Project
● The project is not entirely simple. To explain it to someone took time
and effort.
● This presentation should have been given prior to starting the project
itself.
● There was a lack of motivation among the participants to follow these
ideas, perhaps due to lacking incentives.
● A decision was made to not inform the participants of the individual
projects, of the specifics of this project, to avoid confusion between
Valhalla and Cognizance.
● One unfortunate outcome was that sub-teams were not properly
formed where they should have and would have been useful.

32. Single points of failure.
● If you look at the structure, the leads are a single point of failure.
● If a lead is unavailable, the entire structure is lost. This actually
happened.
● Fortunately the lead that was unavailable was quickly replaced and
tasks were performed on time.
● Secondly, leads required understanding of the projects under their
category, which if inadequate, would be very problematic.
● One of the purposes of maintaining proper documentation was in fact
to mitigate this.
● In theory, a replacement could come in and because of the
documentation, could pick up where their predecessor left off easily.

33. Relation to Cognizance
● A key point of concern was Valhalla’s relation to Cognizance.
● Technically, any forum could be part of Valhalla without contributing
anything to Cognizance.
● Cognizance could be overtaken if Valhalla was followed to the letter,
without regard for Cognizance.
● In fact, several projects had nothing to do with Cognizance at all but
were still part of Valhalla.
● This extensibility may be a good thing, because it provides people a
platform if they want to work on something in the future.
● However, technically, reading a book could also be a project under
Valhalla.

34. The Potential
● The most important lesson to take from this is, in whatever form, it
worked.
● Projects were completed with reasonable documentation.
● Participants learned far more than they could have (or would have)
otherwise.
● Questions raised were answered quickly because of proper
documentation and because a proper process was followed.
● Conflict and interference was avoided wherever the rules of isolation
were followed.
● All in all, the opportunity this presents, and the precedent it sets is very
promising

35. Thank you
Questions, please?