Project Initiation

Once a project is selected it must be initiated, it is in this phase that the project manager learns:

• The objectives of the project
• The business reasons as to why the project was selected
• Information about the project deliverables, Timeline, and budget
• Gains approval to proceed with the project

The initiation phase of a project lays the groundwork for the project

• defines the reasons why they project is undertaken
• the primary business benefits of the project
• the goals the project is expected to achieve
• ensures that all stakeholders are on the same page
• acknowledgment by management of resources required: time, budget, scope
• Project Charter (main deliverable)

Once a project has been added to the project portfolio the organization assigns a project manager to it. The main deliverable of the initiation phase of a project is the charter, the project charter defines:

• Purpose of the project: a simple business statement about what the project is about
• Objectives: are clear an measurable statements as to the results of the project. When defining Objectives make sure that they meet the SMART criteria
• Specific & clearly stated
• Measurable or Quantifiable
• Achievable
• Relevent
• Time-bound
• Key requirements: List what is needed to achiece the objectives
• Main deliverables (Schedualed milestones): a schedual of what will be deliverd and when
• Resources Required: the things needed to deliver the project succesfully
• Budget
• Personnel
• Equipment
• Materials 
• Major Risks: what could prevent the project from being a success
• Schedule
• Budget
• Profitability 
• Technical
• Organizational
• External
• Key stakeholders & sponsers: people who are affected by the project and people who have influence over the project, at a minimum this will be the sponsor, the clients and the team. 
• Project Sign off: this is where the project signed off by the sponsor and PM and client

Stakeholders & Sponsors

Stakeholders 

Not all stakeholders have equal amounts of power or interest in a project, typically the two groups to focus your energy on are whoever is paying for the project, and the personnel who will be using the system.

It's fairly obvious that a you should establish a close relationship with all stakeholders on a project but most importantly those with power and interest, managing their expectations and interests is one of the main keys to a successful delivery.

Not only should stakeholders be identified in the Project charter, but they should also review and sign off on it, to ensure that everyone is on the same page as to what the objectives and deliverables are.

the expectations & requirements of all stakeholders along with their roles & responsibilities must be captured.

Project Sponsors

The project sponsor is usually a management level executive who is championing the project, it is this champion who's identified the financial and non financial benefits of the project and guided it into the project portfolio. This champion usually has a vested interest in the project and thus will be the main source of support for the PM. Usually the Project sponsor is the main stakeholder, the budget is provided by them they are where to go when resources are needed and often times the deciding factor as to what is being built.

The Project Organization

Different organizations have different structures, these differences in organization structure will translate into the organization of a project.

three types of organizational structures are

Functional: also known as traditional, hierarchical or vertical.

Organizations that utilize the Functional structure have a clear chain of command, typically if a project resides inside of a functional unit for example HR, that PM will generally report to the functional head and build the majority of their team from within that functional unit.

Pro's	Con's
Simple	Coordination between functions can be difficult
Direct Access to technical resources	Project can take a back seat to operations
Team members report to their boss

this structure is best when the project is contained within one functional area, since as a PM you'll be reporting to a functional head who's in charge of the personnel, money and scope you'll have very little power, you'll be more of a project coordinator than manager. You'll also be competing against operational priorities for resources. In this type of structure you'll have to rely heavily on soft skills to get what you need to be successful.

Pure Project Organization
this is the opposite of the functional organization, in the projectized organization the PM is the boss, is responsible for time, resources and scope. The personnel are 100% allocated to the project, the PM has full authority. In organizations that utilize the pure project approach to organization every endevour is temporary. Project work isn't organized by function but is rather allocated to a group of resources that come together to solve that particular unique problem.
In such an organization all of the team members report directly to the PM, and only work on their current project deliverables; this type of approach is ideal for multi year projects that require a dedicated team to solve a complex problem.

Pro's	Con's
PM has full authority, all members report to PM	Temporary all good things must come to an end
Simple structure don't have to negotiate for resources	Resources can't be shared, must keep team busy
Direct access to permanent resources allocated to your project	can create duplication
strong team identity and commitment, bonds form between colleagues

Matrix Organization
This organization structure tries to leverage the Pro's of both the functional and pure project organizations. In a matrix organization there are traditional functional units, but the projects will draw members from these functional units, but unlike the functional organization structure the resources are shared by the PM and the functional head, meaning that they have two bosses. Matrix organizations come in multiple flavors, ones that are considered weak will take on more of the traditional functional organization attributes whereas ones that are considered strong matrix organizations will take on more of the characteristics of the pure project organization.

the distinction of whether a matrix organization is considered

• Weak: functional head controls resources
• Balanced: functional head and PM share responsibility of resources
• Strong: PM controls resources

Pro's	Con's
Shared & flexible access to resources	Employees have two Bosses
Resources are project focused	Increased Conflict, employees have to balance operational with project work
Shared commitment between PM and functional head	Communication complexity

As you can see none of these approaches are perfect the trick is to pick the approach that best fits the particular project.

Project length: for projects that are cross-functional and run multiple years the preferred structure is pure project or strong matrix.

# of functional areas needed: when numerous functional areas are required to complete a project than the more valuable it is to use a strong matrix or pure project approach.

Functional knowledge is key: when the project is within a functional unit and the knowledge is very niche than a functional organization may be best suited.

Project Selection

Organizations generally don't have enough resources (people or money) to complete every project they'd like to, thus what they need to do is pick the projects that will have the highest Return on investment. The collection of projects that an organization considers key to it's success is referred to as a project-portfolio; this project-portfolio is a collection of projects that can realistically be completed in a timely fashion and help the organization achieve it's strategic goals, which are high level goals to benefit the company in the grand scheme.

Organizations generally have limited resources, more often than not they don't have enough resources to realistically complete every project they'd like to and thus they need some sort of logical way to select projects with the highest ROI; here are three financial selection processes:

Payback Period
This approach is a simple calculation: Payback period = (Initial investment)/(Periodic cash flow) this means that if our project cost $100 and our projected returns where $20 a year it would take 5 years for this project to break even on the investment, after that the project would begin to generate revenue for the organization. The downside of this approach is that it doesn't factor in the time value of money, meaning that because of inflation a $100 investment today is worth less in 5 years.

Net present value
Is a fairly straightforward calculation where
NPV = sum((ROI per year)/(1+discount value)^(Year Count)) - initial investment

so that means that if your project has an initial investment of $100
a projected ROI for year 1 of $20
a projected ROI for year 2 of $10
a projected ROI for year 3 of $25
a projected ROI for year 4 of $30
and a discount rate of 10%

npv = (20/(1+0.1)^1) + 10/(1+0.1)^2 + 25/(1+0.1)^3 + 30/(1+0.1)^4 - 100

npv = 20/1.1^1 + 10/1.1^2 + 25/1.1^3 + 30/1.1^4 - 100

npv = 20/1.1 + 10/1.21 + 25/1.331 + 30/ 1.4641 - 100

npv = 18.18 + 8.26 + 18.78 + 20.49 -100

npv = 65.71 - 100

npv = -34.29

NPV of 0: project will make enough money to meet the organizations needs
NPV of positive:project will surpass the requirements of the organization
NPV of Negative: project will fall short of the organizations requirements

Profitability index
is a simple ratio
PI = present value of future cash flows/Initial investment,

>1: financial benefits to organization
<1: financial drain to organization also the NPV will be 0.

these calculations are only as good as their estimates.

Numbers are great but sometimes cold hard numbers are trumped by non-financial criteria such as

• Legal requirements: to meet the requirements of a new law
• Competitive advantage: to beat the competition to market for example
• new tech or process: to facilitate earnings in the future.

organization use a combination of financial and non financial criteria to select projects for their portfolio. a typical project selection process maybe something like

1. Business plan identifies project opportunities aligned to the organization's strategy or an employee has an idea for a project and reviews it with their management team for concurrence to proceed and get allocated funding. 
2. Management submits project information on a standardized form. This form typically includes basic level business criteria such as the project goals and deliverables, project purpose, the business reason or business problem addressed by the project, and general information about the project cash outflow, inflow, and market potential. 
3. Project Portfolio team reviews the project suggestions and pre-selects projects based on a set of criteria that best matches the strategic plans of the organization. 
4. Projects undergo additional feasibility studies to confirm viability and confirm the financial and non-financial benefits. This typically includes a review of the project resource requirements. 
5. A final set of projects is prioritized and selected with Project Managers assigned to begin Project Initiation.

organizations will generally stick to their project selection process and not deviate from it. while reviewing the projects in their portfolio trying to ensure that only high value projects are committed to because the more projects an organization is committed to the fewer resources can be allocated to each and thus diluting the value added.

Project Management Office

The Project Management Office(PMO) or just Project Office (PO) is an internal unit that is sometimes set up by organizations to help facilitate project management. They're function is to increase the project success ration by providing support to projects and project managers.

The PMO can provide a wide variety for services

• Be responsible and support the organizations Project Management methodologies and processes.
• Provide Project management expertise and training
• Project auditing
• Support Organizations project management tools.
• Serve as a repository for Best practices 
• Provide standards for collecting project KPI's as well as reporting and measuring project progress
• Facilitate project reviews: lessons learned.
• Help allocate resources across multiple projects.
• Assist with project selection and Project portfolio management. 

PMO's often try to standardize the Project management approach within an organization, keep all PM's using constant PM techniques, tools, and processes. PMO's are responsible to support projects and project managers doing what they can to help increase the success rates of projects.

Initialization before instantiation

Are you telling me that I can initialize a class without running the default constructor? and why on earth would I want to do this?

the answer is yes you can and when you're unit testing.

Within the system.runtime.serialization namespace there's a static FormatterServices class with a GetUnitializedObject(Type) method, this method lets you create a new instance of an object without constructing it.

using System;

using System.Runtime.Serialization;

namespace pav.InitializationB4Instantiation

{

    class Dog 

    {

        string name;

        public string Name {

            get => name ?? "Spot";

            set => name = value;

        }

        public Dog() => Console.WriteLine($"Name: {Name}");

    }

    class Program

    {

        static void Main(string[] args)

        {

            //Create instance of dog without instantiating the object

            var dog = FormatterServices.GetUninitializedObject(typeof(Dog));

            //get an instance of the parameterless constructor of Dog

            var dogCtor = typeof(Dog).GetConstructor(Type.EmptyTypes);

            //Set the Name property to "Fluffy" 

            ((Dog)dog).Name = "Fluffy";

           

            //instantiate Dog

            dogCtor.Invoke(dog, null);

            //instantiate a default dog

            new Dog();

        }

    }

}

and this is what results

Obviously this is an extremely contrived example, but the take away is that you can modify the classes properties before "newing" up an instance of it which can be vary useful when unit testing code.

Xamarin's Command implementation of ICommand

When using Xamarin forms Command class which Implements the ICommand interface, there is one strange caveat to look out for, and that is that the CanExecute func must be declared within the constructor of the ViewModel or have a "Lazy" implementation otherwise it will never fire. What i mean is if you have the following xaml

<StackLayout Grid.Row="2" Orientation="Horizontal" Margin="10,5">

    <Entry Placeholder="Task name" Text="{Binding TaskName, Mode=TwoWay}"

        HorizontalOptions="FillAndExpand" />

    <Button Text="+" FontSize="Large" FontAttributes="Bold" WidthRequest="70"

        BackgroundColor="{StaticResource ContrastColor}"

        TextColor="{StaticResource Backgorund}"

        Command="{Binding AddTaskCommand}" />

</StackLayout>

and it's coupled with this codebehind

string taskName;

public string TaskName

{

    get => taskName;

    set

    {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand { get => new Command(

    execute: () => TaskName = string.Empty,

    canExecute: () => true);

}

Then the canExecute func is evaluated on the initial page load and the execute action is executed whenever the command is called, however it is never called again, namely when the ChangeCanExecute method is called from the TaskName's setter the condition is never reevaluated and the add button remains in whatever state it was on the initial page load.

Let's add some logic into the can execute func

string taskName;

public string TaskName

{

    get => taskName;

    set

    {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand

{

    get => new Command(

        execute: () => TaskName = string.Empty,

        canExecute: () => !String.IsNullOrEmpty(TaskName));

}

now under these conditions the "Add" button shall never become enabled. Now if we simply assign our command in the constructor of the view model everything works just fine.

string taskName;

public string TaskName {

    get => taskName;

    set {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

public ICommand AddTaskCommand { get; private set; }

public ProjectPageViewModel()

{

    AddTaskCommand = new Command(

        execute: () => TaskName = string.Empty,

        canExecute: () => !String.IsNullOrEmpty(TaskName));

}

bizarre yes, why you may ask? well a kind soul pointed it out to me that in the above implementation every single time you call the AddTaskCommand you receive a new instance of the Command implementation, which is why it works when you assign it in your constructor but not when you define it inline. So another alternative to defining all your Commands in your constructor is to use a backing field for the AddTaskCommand property and use a lazy implementation for your commands.

string taskName;

public string TaskName

{

    get => taskName;

    set {

        base.SetProperty(ref taskName, value);

        ((Command)AddTaskCommand).ChangeCanExecute();

    }

}

ICommand addTaskCommand = null;

public ICommand AddTaskCommand {

    get {

        this.addTaskCommand = this.addTaskCommand ?? new Command(

            execute: () => TaskName = string.Empty,

            canExecute: () => !String.IsNullOrEmpty(TaskName));

        return addTaskCommand;

    }

}

in the above we check if the addTaskCommand backing field is null, if yes then we assign an instance of command to it, if not then we just return it, this keeps us from having to define all of our commands within the constructor.