The Child Welfare Information Technology System Project Lifecycle, Part 1


>>Coordinator: Welcome and thank you for
standing by. All parties will be able to listen-only until the Q&A portion of today’s conference.
If you would like to ask a question during the Q&A portion you may press star-1. To withdraw
your question you may press star-2. Today’s conference call is being recorded.
If anyone has any objections you may disconnect at this time. I would now like to turn today’s
call over to Ms. Joyce Rose. Ma’am, you may begin.>>Joyce Rose: Hello. I first want to apologize
for our delay. We had a couple of little technical glitches but hopefully they’re all worked
out and welcome to Webinar two of the Back to Basics series. This webinar will review the initial stages
of a child welfare project lifecycle and it’s brought to you on behalf of the Health and
Human Services Administration for Children and Families Children’s Bureau. I am Joyce
Rose, your host and moderator for today’s webinar. Joining me a bit later will be Colleen
Mousinho and Scott Rogillio. So changes in funding availability and priority
mean that opportunities for in person discussions and networking among professionals working
in State child welfare IP systems will be limited this year and likely in future years. Through this webinar series the Division of
State Systems within the Children’s Bureau is offering a venue for information sharing
and discussion. We will be offering six webinars, one per month between April and September
2013. While the webinars offer some structured content
our goal is that they will spark discussion and information sharing within and across
State and federal attendees. The webinars are intended not just for child welfare IT
systems managers but also the staff with whom they work who are key players in keeping child
welfare IT systems up and running. Although our series theme is Back to Basics
we invite and encourage participation from both experienced and newer managers and staff,
recognizing that even the most experienced among us have something new to learn or may
need a refresher in the rapidly changing field of child welfare information technology. This and all future webinars are being recorded
and will be made available online as reference and informational resources for you and your
staff. A global notification will be distributed once this webinar is made available with instruction
on how and where to access. Today’s second webinar in the Back to Basic
series, the Child Welfare Information Technology System Project Life Cycle Part one of two,
we’ll review at a high level key project challenges and stages that we all face as
project managers. The continuing topics in the Back to Basic
series are Webinar one which we completed last month and has been posted online. If
you have a pencil handy you may want to jot down the URL that is on this slide. Then we will be doing Webinar 2 today which
is Part 1 of the two-parter covering the project lifecycle. Then we will move Webinar three,
which is Part two of the stages of the lifecycle. And again, let me stress that this two part
webinar is about the project lifecycle and not the application development lifecycle. Moving to Webinar four in July we will review
common pitfalls and how to avoid them. And then we are actually in the process of finalizing
the topics and other details for Webinars five and six. But please watch for more information. Attendees are encouraged to participate in
our webinar with questions and or comments. All of our participant lines are now muted
but we will open them at the end of the presentation for discussion. You also can submit questions
through the go to webinar chat feature. So we will save those questions until after
the presentation has been completed. Should we run out of time we will respond to your
questions via email and or should you have additional suggestions you may submit those
to me at the email address listed on this slide. So you may quickly want to jot down my email
address just in case you want to send me some suggestions for future webinar. So we are very interested in knowing who is
attending this webinar in terms of both position and capacity. We ask that you self select
one of the five categories listed. Also recognizing that not all States are [unintelligible]
States and to be inclusive of everyone we will use the more generic child welfare information
system, CWIS identifier. My colleague, Elizabeth Mertinko will manage all of the polling questions
and summarize the results. Elizabeth?>>Elizabeth Mertinko: Yes, we have the poll
up and running and people are still responding so we’ll just give them a couple seconds
to catch up with us. It’s a pretty – it looks like it’s a pretty varied group today. And it looks as though we have 23 percent
State child welfare information system project managers, 7 percent program managers, 23 percent
technical managers, 33 percent project staff, and the remaining 15 percent CB personnel
or ACF contractor staff.>>Joyce Rose: That is a great representation
of the entire staffing of an IT project such as the size. So that’s excellent. We are
also interested in learning what the level of experience is within the CWIS environment.
Are you a relative newcomer? Are you one of those well experienced veterans.
So Elizabeth, could you conduct this poll please?>>Elizabeth Mertinko: Yes, I just launched
it and people are responding. And again, it looks like we have a pretty varied group today.
And with our voting slowing down it looks as though 15 percent are relatively new, zero
to two years of experience; 9 percent two to four years; another 9 percent four to six
years; 18% six to eight; and half – 50 percent nine years or more.>>Joyce Rose: Wow, again, that is a great
representation and I am very pleased of the number of zero to four year participants that
we have, thank you so very much. So then one other attendee poll, please. We would also
like to know if there are repeat versus new attendees to our Back to Basics webinar series.
Elizabeth?>>Elizabeth Mertinko: Yes, I have just launched
and our first webinar Back to Basics was our Fundamentals of a Child Welfare IS Manager
and that was back on April 18. And with our voting slowing down almost half and half,
about 41 percent did and about 59 percent did not. So for those of you who did not be
sure to visit the Children’s Bureau website and catch the recording of that.>>Joyce Rose: Yes, and it is gratifying to
know that our – obviously our first webinar hit the topics and was useful that we have
repeat customers and, again, I’m very pleased that we have new attendees. So thank you very
much. So let’s quickly look at today’s agenda.
The format of this webinar is approximately 35 minutes of content presentation, 30 minutes
of guest presenter dialog, and then we will invite all attendees to participate in a 20
minute Q&A session followed by a short wrap up. I will start with introductions and then move
on to the topics relative to a project lifecycle starting with planning, moving to procurement,
talking about relationship management, talking about managing priorities effectively through
tools such as risk management and change management, our Q&A session, and then our wrap up. So let’s start with some introductions.
Our two guest participants probably need very little introduction but let me briefly introduce
and extend a warm welcome to both Colleen Mousinho and Scott Rogillio. Colleen is the interim director of federal
regulations and data and has been on the Georgia SACWIS SHINES project for the last nine years
serving as the program manager for five of those years and then four years as the Director
for SHINES. Colleen brings more than 20 years of experience in child welfare to the table. Scott has a diverse background working in
both the public and private sector. He received a BS in biomedical engineering from Louisiana
Tech in 1993 and then subsequently worked for both NASA and then Accenture. In 2003,
Scott joined the public sector developing the Texas Controller Mobile Tax Collection
system. In 2010, Scott joined the Texas Department
of Family and Protective Service as Director of Application Development and Maintenance
where he is today, responsible for all internal agency applications including Impact which
is the State of Texas SACWIS system. We are pleased to have both experienced and qualified
individuals as our guest participants. And myself, formerly project director for
the State of Wisconsin SACWIS project, retiring from State service in 2004 and since that
time I have been involved with several ACF Children’s Bureau sponsored training events. Let’s begin with the planning stage of the
project lifecycle. Project planning is essential for a project’s success, that’s what helps
team members to understand the responsibilities and expectations and also this phase identifies
scope, tasks, schedules, risks, quality, and staffing needs. Now in project management speak, the project
planning phase follows the project initiation phase and is considered the most important
as the efforts spent in planning may save countless hours of confusion and rework in
the subsequent phases. The project definition encompasses the identification
of the business and technical drivers, expected outcomes are defined, and where a clear understanding
of what the business objectives are exhibited. Never assume that you understand the end user’s
problems and needs if you have not worked closely with them. Therefore, fully engaging end users in the
project definition process elabortively documents a shared vision of the final project, describes
the problems and needs to be addressed, and also creates the foundation of trust and communication
that will be needed throughout the project lifecycle. Resource planning is a long term, forward
looking view of resource requirements and it is used to manage at the project level.
Resource management is a detailed day-to-day view of resource allocation and it is used
to manage projects at the resource task level. Resource planning involves determining what
physical resources such as people, equipment, or materials and what quantities of each will
be needed to perform project activities with the objective of this step in the process
– to step in the process being to identify high level resource requirements for the lifecycle
and composition of your project. However, it may be necessary to complete the
project requirements in order to fully determine the quantity of both the internal and external
skills and resources needed to successfully complete the project; remember, projects are
led by people not technology. Although technology can help such as a state
of the art project management and software development tools, it is the leadership of
a project that makes all the difference. So planning project resources carefully and
with great pause is often the most challenging phase for a project manager as the PM needs
to make an early yet educated guess of the physical resources needed to successfully
complete the project. Bottom up resource planning focuses on the
level of effort needed to complete the tasks required of the project. This approach typically
begins when project managers develop the work breakdown structures, WBS, that include the
individual tasks that must be performed to complete the project. This level of resource planning can be extremely
valuable in helping project managers to develop critical task schedules and milestones and
to manage day-to-day resource needs and conflicts. However, the level of detail required can
be very, very time consuming. So typically the bottom up approach is most common where
the complexity of the project requires detailed planning and resource management. Certainly
a highly involved and complex project such as a CWIS initiative is deserving. We all know that the vendor community who
engage in a CWS go to this level of detail using some project management tools such as
MS Project and as evidenced by the detailed project plan deliverables provided to the
State project manager, not only at project inception and then – but also maintained throughout
the life of the project. Top down resource planning takes a high level
view of the types of resources that will be required to support a project such as a SACWIS
and the length of time they will be needed. This approach is often applied early in the
planning stage of the project before detailed specs are available to the project team and
often long before a detailed project plan has actually been developed. Usually resource
needs are defined in terms of skills and put into large time buckets. Now as I look back, this was my early approach
when planning the Wisconsin SACWIS resource needs, putting defining skills and putting
them into large time buckets. But then, you know, I found myself just hoping
and praying that not only the skills and the resource numbers but also the time buckets
and commitments were actually sufficient. And I’m sure, I bet, you all have experienced
those pains. Regardless of the approach incorporating resource
planning provides significant benefits such as aligning cross-functional teams with project
goals and constraints from the beginning stages of a project, which may eliminate contentious
discussions later on. Resource planning also provides the early
identification and understanding of needed skill sets whereby staff expansion augmentation
or cross training may be needed to meet the project and organizational objectives and
by agreeing on initial timing and resource allocations early in the project. The organization really creates a constant
message of expectations and commitment to the project. Of course, fully engaging your executive sponsor
is another key to securing the needed resources as in most cases it is they who are the final
decision makers and who can actually make things happen or not. And this is also a perfect
time to start building an open line of communication and trust with your executive sponsor. Certainly study of other State projects may
assist in identifying the right configuration of skills, the number of resources, and time
commitments. So moving on to the next stage, which is procurement.
In most instances, the instrument used to procure vendor services is a request for proposal
or RFP. This method is a standard procurement practice designated and supported by local,
State, and federal government entities. So often times time consuming and also labor
intensive, the RFP continues to provide States with the most straightforward process for
the acquisition of large scale IT purposes. There are several approaches to use to develop
an RFP but the most critical deliverable and goal is to develop a complete, precise, and
well written document whereby the requirements are explicit, easily understood, and can be
universally interpreted by all potential responders. Now prior to developing the RFP the organization
must first determine what application development or procurement model best fits their needs.
The existence of a baseline application whereby the SACWIS or child welfare information system
functionality closely matches your programmatic and technical requirements is one procurement
method to consider. While the transfer method may provide some
efficiencies consideration should also be given to engaging in a new development project
or even a [unintelligible] solution. As you build the RFP it is critically important
to fully understand the stakeholder and end user needs and identify the problems, issues
which the application is expected to address or resolve. Remember please that people cannot
effectively control nor manage what they don’t understand. An end product that is on time and within
budget but does not meet quality requirements or other expectations will result in significant
implementation and continuing end user acceptance problems. The most common requirements related problems
are first ones are stakeholder problems and corresponding needs are not fully understood.
Secondly, stakeholder problems and needs are not explicitly documented. The third one, agreement has not been reached
from the validity or the content of the requirements. The fourth, changes to an agreed to requirements
document are not controlled and communicated. And five, project document version control
problems exist. In terms of the project documentation, the
product requirements document literally represents the foundation from which the product solution
will evolve. The time and energy invested in ensuring a thorough review by the affected
stakeholders may be the best investment that can be made throughout the software development
lifecycle. In terms of evaluating responses, each State
as well as each member of the evaluation committee must follow its own clearly articulated RFP
procurement processes. Putting together the right team is one of the initial and most
important steps in the process. Drawing on the appropriate individuals that represent
key stakeholder groups helps establish buy in of key stakeholders, especially front line
workers and other intended users of the system. States typically use a prescribed evaluation
methodology defining several elements including cost, quality, references, and meeting performance
bond and other special organizational requirements. While cost is a major factor in determining
the eventual award it is best practice to withhold the bitter cost data from the evaluation
team until all other scoring has been complete. Award and contract negotiations, of course,
State procurement rules must be satisfied and the Children’s Bureau must be in agreement
that the completed procurement process and the potential award met the principles of
fair and open competition. The set expectations for a positive project
startup, both the State and vendor contract negotiation teams should really have three
goals in mind; the first, to reach satisfying agreements for both parties; secondly, to
reach agreements efficiently; and third, to conclude negotiations on a positive note. Once that is done it is project startup time
and here is where the project manager begins the daily management of a CWIS or SACWIS project
as well as taking the responsibility of vendor contract administration. Now in its basic form contract administration
is simply managing the project lifecycle relationship with the vendor. Contract administration includes
monitoring enforcing the processes and procedures, schedules, deliverables, responsibilities
negotiated within the contract, and ensuring compliance with the terms and conditions set
forth. The important thing really is to get your
project started on time with all committed staff onsite and everyone is focused upon
starting off on positive footing. In terms of submission of documentation to
ACF it really is – it really is sequential. So the documentation submissions to ACF, if
you are requesting FFP and if the project threshold is greater than $5 million is sequential
in nature. Step one is to submit the RFP for approval prior to release. The second step then is to submit an APDU
update with a high level schedule of events. Moving to the third step, here’s where you
do your negotiations and make your vendor selection complete. Complete those negotiations. And then the fourth step is to submit the
contract for approval to ACF prior to State signature. A warning here, do not as a State
sign that contract before it is submitted to ACF for approval. And then finally, once everything is approved
you need to submit APDU update with an updated project plan and a copy of the signed contract. Now there are several artifacts that actually
make up the contract portfolio; the RFP, of course, the final statement of work which
is the revised work plan or schedule of events including deliverables and payment schedule,
the accepted financial including the best in final offer or the BFO, the agreed upon
price here. The fourth item is the State and vendor legal
limitations and associated remedies and then your detailed project processes. And it’s
a sequential submission of documentation to ACF and the procurement process. So let’s move on to relationship management.
Managing the wide array of stakeholders for a complex CWIS project is a major challenge
for the project manager as well as the project team. A stakeholder is defined as any group or individual
who can effect or is affected by the achievement of an organization’s objective and in this
case, the implementation of a statewide SACWIS system. There are two major – two types of major elements
to stakeholder management. There is stakeholder analysis and then there is stakeholder planning. So stakeholder analysis is the technique used
to identify the key people who have to be won over and then secondly use stakeholder
planning to build whatever support may be needed that helps you to succeed. So project stakeholder management is a key
skill and stakeholders can either make or break your project because they are the people
that have an interest in the project outcome or process. That interest can be either positive, wanting
the benefits of the outcomes or processes that your project provides, or negative as
that type sees the outcomes or mandatory processes from your project as a hindrance to them. The importance of managing stakeholders, obviously
your stakeholders will need to be managed through every phase of your project. Start
with involving them in clarifying the scope of your project and identifying possible solutions
to meeting the goals that the project is designed to solve. As the project proceeds draw up a communications
strategy and a communication plan that identifies how, when, and what to communicate to each
stakeholder group. Part of this involves project reporting. Think about how and when and to
what level of detail you will deliver project reports to each separate group of stakeholders. Now the benefits of stakeholder management
are that you can use the options of the most powerful stakeholders to shape your projects
at an early – I’m sorry, use the opinions of the most powerful stakeholders to shape
your project at an early stage. Not only does this make it more likely that
they will support you, their input can also improve the quality of your project and its
deliverables. Secondly, gaining support from powerful stakeholders
can help you win more resources, specifically internal program support staffing or other
IT related sources – resources. This makes it more likely that your project will be successful. And by communicating with stakeholders early
and often you can ensure that they know what you are doing and fully understand the benefits
of your project. This means they can support you actively when necessary. You can anticipate what people’s reaction
to your project may be and this will help you build into your plan the actions that
will win other people’s support which really is a marketing gesture. Bottom line is that you will find that different
stakeholders will want very different outcomes from your project thus a vital part of stakeholder
management is managing these competing expectations from the initial phase to final implementation. In our SACWIS or CWIS project environment,
stakeholders may include our federal partners from the Children’s Bureau or other federal
partners, State and county project sponsors, project steering committee members, business
units, and line managers, project team members, other State or county departments, and county
departments when a State is State managed and county administered whereby they supply
resources, infrastructure, and expertise; our vendors, contractors, and consultants
supplying services to your project; other government entities and of course, advocacy
groups that have their own unique set of interests. All of the stakeholders mentioned are of the
strategic variety meaning that any one in that group can achieve – can affect an organization
and must be managed so objectives can be achieved. Each group needs to be communicated with in
different ways so consistent messaging is vital. And here’s where a suggested project
communication plan is developed and implemented as it can be an effective tool to achieve
transparency and consistency. So let’s move to the first segment of our
guest participation, our guest participant discussion. Colleen and Scott, are – do you
have your phones unmuted?>>Colleen Mousinho: Yes, I just unmuted.>>Joyce Rose: Scott, are you there? Okay.
Well, Colleen, we’re going to ask you in Georgia do you manage your stakeholders differently
today than when your SACWIS was first being developed and implemented?>>Colleen Mousinho: Yes, we do. And Joyce,
I think you did a great introduction into stakeholders and how important they were.
And we – I think we could have done a few things differently when working with the group. I think one of the biggest groups, of course,
you mentioned is our vendor and I think for the vendor that’s – managing the vendor’s
probably a whole series or workshop by itself. But I think the critical thing for us with
that – and you mentioned the RFP, was that for us the vendor management piece really
started with the RFP. When we put in there certain conditions we
inserted that we wanted final approval on staff changes and we identified who the key
staff were and we said that they needed to be onsite and we needed to approve who the
key staff were. So when we first started with SHINES we actually
interviewed the different vendors that responded to the RFP. And we’ve continued that process.
I think this is the one thing we haven’t – would say that hasn’t changed for us,
we continued that same requirement through the maintenance cycles when we renewed the
contract or continued with the option here. So I think it’s critical to – I think that’s
a critical piece towards managing the vendor is managing who the staff is and looking at
their experience and their expertise and having a say in that. I think that’s critical.>>Joyce Rose: Colleen, I have – let me interject
here just for a second. You are talking about interviewing the vendor staff.>>Colleen Mousinho: Yes.>>Joyce Rose: Also, and I’m going to just
add this in, when developing an RFP States should not be hesitant about putting in as
much as possible about these State project teams. The vendor assumes significant risks
and risks are interpreted into money and when a vendor can be assured that the State staff
is more experienced or has significance credentials that risk can be reduced.>>Colleen Mousinho: Good point.>>Elizabeth Mertinko: Joyce, I just wanted
to interrupt. Scott, I think you are on the line but I think you’re muted. So if you
could press star-1 and Operator, if you could let us know when Scott’s queued up that
would be great.>>Joyce Rose: Thank you, Colleen. I’m sorry
I interrupted. You can continue on.>>Colleen Mousinho: Any time, that’s fine.
So for us – as far as the rest of the stakeholders was concerned, SHINES rolled out in 2008 after
multiple attempts in the State to get a SACWIS going. So when we – we were a new project
team. And so when we came onboard we were faced
with a lot of skepticism from both the internal staff and from our external stakeholders as
to whether or not this attempt would successful. The other thing was our staff were used to
seeing, you know, other initiatives come and last for a minute and then they went away.
So they had that mindset as well going into this that, you know, Georgia SHINES or the
SACWIS system has yet to be named would be something that may be fleeting and would not
be here for a long period of time. So we had to do a lot of communication. We
had to over communicate with both our internal and external stakeholders. We did a lot of
face-to-face meetings, we did a lot of road shows, we sent out a lot of emails. We created a document called a Change Discussion
Guide, I don’t know if anyone’s familiar with that, but it describes current state
and then it describes that to-be state. So we spent – our messaging not only was about
benefits but we also had to try to build trust with our stakeholders helping them understand
that this was a major investment for the State and something that they could – that was solid,
that was going to be here, that’s something they can rely on. It helped that we had the Governor’s office
behind us. We had to report to the Governor’s office about once a month. And our executive
steering team was comprised of folks from, you know, the Governor’s level and staff
that reported directly to them – to him and individuals from the legislature. So we had a pretty strong showing and a pretty
strong showing of support so that our stakeholders helped, again, message we’re here to stay,
we’re not going anywhere. This is something that you can rely on. So that was our main
trust and focus when we first had to work on rolling out Shine. Once SHINES rolled out over the years we’ve
worked really hard to show that we have a good product. And the stakeholders are now
wanting – as opposed to go away, we don’t think you’re going to be here, they’re
now starting embrace us. They’re now wanting a say in what we design and what we produced
and what we put in SHINES and how SHINES works. So we created an advisory board and it’s
made up of field staff from all levels. We’ve got case managers and supervisors, county
directors, all the way up to regional directors. And they’re a part of our change management
process, they prioritize our work as well. So that group has – we are an advisory – it’s
an advisory board but we’re – we sort of attend as kind of their leisure and their
invitation. So they have some say so. They’re a strong board and the word I’m looking
for I guess is empowered, they’re empowered. So we work with them a lot. And they are our
champions for the field so they help spread the word and increase the acceptance and understanding
of SHINES. We’ve now included our providers. We didn’t
initially. We created a portal and our providers have limited access to SHINES. So we do some
work with them. We’ve – we attend their meetings, we share data from the system. So
we’ve definitely got people who are now on board with the system and want to participate. And they want to help as opposed to – you
mentioned earlier the stakeholders can either oppose or they can be your advocates. So we’ve
moved to having stakeholders that are now advocates for SHINES. We work with the courts, they’re one of
our interface partners, but in addition to discussions around just the interface we’re
now talking about practice and how we can help – we could work together to improve practice.
So our stakeholders are now part of us and it’s become more of a joint efforts and
improving SHINES than it was previously. ACF is a critical partner for us. When we
first rolled out SHINES we spent a lot of time with ACF getting a lot of TA around the
schedule, budget. Again, you know, they had seen us try this many times before, were not
successful. So to be honest they may be – they may have
been a little skepticism there but as they worked with us and see – they’ve helped
us become successful. So we still have that TA and relationship.
The conversations happen less frequently. We’re now down to once a month versus several
times a month. But that’s another critical stakeholder that you need to make sure that
you are working very closely with.>>Joyce Rose: Fantastic. So let me see if
I can just do a very quick summary here. In terms of marketing tools you created a – the
as-is/to-be vision and shared that and got that out and about. You created champions.
You expanded access creating additional advocates, creating a joint effort, and then developing
that trusting relationship with ACF.>>Colleen Mousinho: Yes.>>Joyce Rose: That’s great Colleen. Thank
you very much. Scott, are you unmuted now?>>Scott Rogillio: Hi. I think so. Can you
hear me?>>Joyce Rose: Yes I can.>>Scott Rogillio: Great.>>Joyce Rose: Has Texas done anything differently
in terms of managing your stakeholders or doing some unique marketing stuff?>>Scott Rogillio: Yeah in the, with the large,
when we went with the large changes and basically in 2003 when we went from a client server
to a Web application we were becoming compliant Texas is spread across 12 regions and they
wanted input from all the you know all the regions. So we actually pulled in several resources
from all the regions to work on the project, as you can imagine that’s a lot of travel,
a lot of people relocating and you know and they’re vacating spots, they were allowed
at the time to repost those positions and fill those because it was a multi-year project
going on. But they really wanted people from the different
regions to be here on the ground day in and day out from the requirements to the design
to how this is going to be communicated out to the training plans and that was for, you
know the overhaul, a very large you know very rushed short time frame effort. One of the things that, one of the remnants
of that is a group that was formed when that project was kind of completed was our program
support group, several of the key individuals that played a role in those they were, you
know obviously case workers, supervisors, they formed a new group called our Program
Support Group which are functional analysts and testers. And they stay here now and they’re housed
in our building with IT and we work hand-in-hand you know whether it’s a change request or
a project it’s always programs making a request, program support with their functional
knowledge and expertise and IT we form the core team, those three units and we work on
projects enhancement requests, defects together. But that was kind of one of the outcomes or
I guess new groups that were formed, several staff didn’t go back to their field offices
that they remained here in Austin and started that group. For new projects we have we can’t bring
in you know, people across all the regions for the state so we do lean on our local field
offices, try to hit some more in the city and some in the rural areas, and pull those
users in to (JAD) sessions and provide, have them come in for UAT. Now you can imagine every project we have
we’re constantly going back to the same offices asking for staff and that’s been
kind of one of the I guess the downfalls is we hit hard a couple of these local field
offices and it’s hard to pull at the same staff so they can keep their statistics up
but it’s truly what we feel that we need their feedback, they’re the ones using it
day in and day out. You know just like IT does, we need, we need
to build something that the users request and meets their needs and kind of the same
thing state office sometimes can, what we call state office can be disconnected from
what’s really going on in the field so executive management has really understand that and
really see the need that we have to get out and pull in people that actually are going
to be using this day in and day out and then pull those into our projects early on. And then we also try to bring them back in
at the UAT stage just prior to deployment to have them look at our training material,
go over one, you know the messages that are going out, look at the final application before
it’s deployed in the last three or four weeks just to see if we can polish anything
up, tweak the communications going out and make sure that it’s going to be a successful
deployment.>>Joyce Rose: Great. So on top of the unique
things that Colleen in Georgia put together we can add this creation of this program support
group that Scott in Texas put together because I think we all realize that the better integration
there is between program and technical the easier things are in terms of decision- making
and getting to done. So thank you both for your input. Let us move now to
managing priorities effectively using in this
case risk management. Risk management is defined as identifying a concern before it becomes
a crisis or a threat to the project. Risk management activities include assessing situations
that have a potential adverse impact on the success of the project and taking steps to
mitigate that potential risk. In some situations the project manager can
only reduce the consequences of the risk that cannot be avoided. Consequently, the goal
of risk management is to improve the likelihood of achieving the project’s goals and objectives
by simply peeking over the horizon and discovering any dangers that may be looming. In order to assess the impact of particular
event or circumstance on project success, it is necessary to understand the goals and
objectives of the project. The relationship between risk events can be mapped to which
project objectives may be most adversely impacted. Risks that do not jeopardize project objectives
can be eliminated from consideration or simply categorized as low risk, for which no actions
may be required. Any risk with a high or medium probability
of occurring should have a risk mitigation strategy identified. Planning proceeds the
accomplishment of work therefore a high level risk management plan should be developed which
defines the process ACWIS project will use for risk management as well as risk mitigation
strategies. In summary, risks are inherent to every project.
Dealing successfully with risk requires that risk management be incorporated as an ongoing
iterative process rather than a one-time activity. Bottom line assessing and managing risk increases
the probability of project success. So our chart here the first step is risk discovery
where we identify new risks or we identify changes in already known risks, so that could
be a change to the probability, or impact due to some change circumstance. The second step is to do risk analysis, here
is where you do your risk estimation of what is the impact and also what is the probability
of that risk occurring and you want to do a bit of risk aversion practice, how much
is okay, how much can be reduced and how much can be avoided. And then finally is risk mitigation, here
you develop strategies to reduce that impact to reduce the uncertainty, you want to create
options to [unintelligible] that may occur and you want to adjust success targets. So moving then to change management in a project
management context change management refers to a project management process wherein changes
to a project are formally introduced and approved. Change management is initiated and administered
throughout all phases of the project life cycle to accurately maintain a system, software
and documentation and to control changes. The change control process is used to manage
changes to materials that have been marked final or for enhancements outside of the original
project scope. There are generally three conditions, which
may initiate a change request. Changes to processes, enhancing functionality, usability
or scope and/or new requirements. Now [unintelligible] the CWIS project manager
is to implement a project change management process and then to monitor its application
and consistent use throughout the project life cycle. So our chart is a generally accepted change
management process with six steps and this is very easy to understand and what I want
to do is move on to our guest participant discussion. Scott, I’m going to start with
you, what processes do you use to select and prioritize change requests for your SACWIS
and then what are the biggest challenges to your SACWIS change management processes? And I have to tell you that I have to call
in on another phone so I’m going to let Scott and Colleen chat away and I will be
back shortly.>>Scott Rogillio: Okay. How do we select
and prioritize our changes for our SACWIS system here? We go through once a year, and
we’re actually in the cycle right now, we try to prioritize our projects at a high level
and then later we will actually do quarterly prioritization of what we call just servers
which are kind of our change requests. They could be enhancements, there could be
defects, there could be data changes but the work is kind of classified in two major areas,
is it the new functionality or new enhancement that’s coming in. And we go through and we actually to help
the executives we have a lot of estimating tools that we use here to figure out how many
hours it’s going to take from a project management perspective, a business analyst,
development which how many hours per development team whether to Java resources, batch resources,
data admin resources, if there was any interfaces we have to bring in other agencies or other
development teams. So part of our prioritization is to get all
the requests in we have a time frame where we ask program to if they haven’t already
submitted their project concept proposals, which are about five to six page documents
that we have estimates on we ask them to submit their request. We try to scope it as quickly as we can to
get something to work with, hopefully we have a PCP which is much more detailed and we have
a lot more time and thought to put into what the level of effort’s going to be. Then we actually do a lot of forecasting,
we track all of our time the time accounting system and we can actually forecast what percentage
of our time is going to go to major buckets. For example, we know how many hours, about
20 percent, 25 percent of our time goes to admin and we strive to have about 47 percent
of our developer time toward new projects, about 20 percent of our time toward change
request. There’s also production support, release support and those are the main areas
that we track. So we can actually forecast that my teams
have X amount of hours to contribute to projects and then it becomes very simple for the executive
team to look at 10, 20, 30 project requests, see the funding we have and see our resources
available and then they do their prioritization and we know when we’re full. We know when we, when our project teams are
at capacity and when we have to bring on staff augmentation or do we go outside and look
to do this as a here in the state of Texas we have a different, we have two different
RFPs, one is a broad sense of an RFP for a contract, or our Department of Information
Resources, DIR, has put together what we call a debits contracts, which is delivery based,
it’s a smaller contract that can’t exceed $10 million, it has certain vendors that have
been pre-qualified and we can also use that as a method. That’s the major projects. So as we’re
forecasting our FY ’14 right now we will have down to the week where all of, where
all our projects would be, how many hours we’re going to be spending in the broad
ranges around requirements, design, development, testing or deployment. We’ll then have leftover hours that we can
put in our quarterly releases for enhancement and break fix changes. We have a server view
commitment, the team will come together from the project liaisons, program liaisons and
they’ll have a list of enhancement servers, defects that they want done. Our development teams will come in saying
we have available so many hours forecasted that we could work on these, they again prioritize
you know based on what they need and the hours that are available and the requests we already
have estimated out the hours that are available for that. And we’ll come up with we can do this much
work and that’s kind of how we do our prioritization. The other question was what are the biggest
challenges around the change management is there’s always a lot more requests on the
table than we can get to, even you know, there’s always 100 things and we can only do 20 and
we follow a waterfall approach and a lot of times it’s perceived that if it takes too
long that we wish we could, you know, program wishes they could have more done in a shorter
amount of time. So to help educate our users in our program
office we put together two training sessions over the last two years, one was for middle
management and kind of almost up to the executive management levels to there was a kind of a
very similar PowerPoint that we we’re going through right now, what does it take for projects,
what is required? What is required for federal documentation and reporting for our own state
documentation and reporting? Why do we do this? It’s just we don’t like writing documents
but it’s best practices, we want to make sure that requirements through requirement
trace ability matrix is that requirements that are asked for up front actually make
it into the design it’s, there is a process and it’s not just madness that we’re doing,
and then there was also the second training which was around this server or our change
request. Again here’s the process, these are all
the steps to make sure that what is asked for has been thought all the way through and
that what is delivered doesn’t break other things in the system. So those are two things we were trying to
help educate our end users, our customers on the processes we go through and why we
do it and once a year we kind of sit back and say what can we do to improve on this
and these two training sessions came out of the last two years of us talking what can
we do to help improve the relationships between IT and our customer. That’s where I’m going to kind of leave
it all those two bullet points for now.>>Joyce Rose: And I am back so I appreciate
it. Colleen?>>Colleen Mousinho: For us in Georgia our
number one priority usually is around SACWIS compliance. So that goes first on the list,
then as I mentioned we have the SHINES Advisory Board, they help prioritize and they’re
also part of the decision-making team in the sense that if we have two items or three items
we need to decide amongst, and it’s not related to SACWIS compliance then they get
to pick which one makes sense and which one is impacting the field, if they are of the
field and that gets on the list. We also get requests through our help desk
and then we get requests through our business users and business units. So we take all that information, we put together
a project plan for the year; again you know SACWIS compliance goes on there first of course.
And then you know I’m going to go, that’s our process and we sit there and we work with
the vendor, we lay out a release schedule for the year, we set up our deployment dates
so we have our plan in place. I agree with Scott, we have the same challenges
around funding, you know the field, thinking we need to be able to turn around the request
quicker than we can. The other challenge for us and the biggest challenge for us when business
decides to initiate these huge changes in the workflow or the business model or the
safety model and that becomes the priority. So the compliance issue or other things we
have on our list shift and have to move down in priority and we have to be able to respond
to the business. We also get, and we also may give an initiative from the governor’s
office where they want something implemented pretty quickly. So as much as we plan we have to be very flexible
in child welfare I feel, I don’t know how it is in other entities or you know other
environments but I know in child welfare it change so much here that you know we have
to be able to respond to leadership pretty quickly.>>Joyce Rose: I would suspect that most all
states have, are enjoying the same challenges to their change management practices and processes
that both Scott and Colleen are. I think what we’ve heard is you know funding and time
and you know being a good juggler and by all means being flexible is an excellent quality
for a project manager on a SACWIS system. So thank you very much to both Scott and Colleen
and it is now time for our attendee discussion and I encourage anyone to open your phone
line and to ask our distinguished panel any questions you may have or to submit questions
again in the chat feature, so Elizabeth do we have questions?>>Elizabeth Mertinko: We don’t have any
through the chat feature but Crystal could you go ahead and remind everybody how they
can line up and ask questions via the phone?>>Coordinator: Thank you. As a reminder if
you would like to ask a question please press star 1 at this time unmute your phone and
state your name. To withdraw your question you may press star 2. Once again any questions
please press star 1 and state your first name.>>Joyce Rose: So we have a large audience
participation. I would suspect there has to be a question or two out there somewhere and
we’ll give you a few minutes to press star 1 and ask your question. Anything by chat, Elizabeth?>>Elizabeth Mertinko: No. Nothing by chat
at this time. I do want to take a minute though, I know you’ve already thanked both of our
state presenters but I wanted to thank you as well, I think hearing directly from people
in states who are doing this work and doing it currently is invaluable so I just want
to thank both of you for sharing your past experiences and your goals for the future
and for being a part of the discussion today.>>Joyce Rose: And I second that. Thank you
Scott and Colleen.>>Colleen Mousinho: You’re welcome.>>Scott Rogillio: Yes. You’re very welcome.>>Coordinator: We do have a question on the
phone lines.>>Elizabeth Mertinko: Okay thanks Crystal.
Go ahead.>>Coordinator: You’re welcome. Our first
question comes from Karen. Your line is open.>>Karen: Okay. Thank you and it’s a group
of us in the room participating in the Webinar. And it was a question for Scott. We were wanting
to know if he made reference to using a tool to help estimate time needed to complete a
change request or a major initiative in a system change and we were wondering what kind
of tool or what is it an automated tool or what is the tool or process that they use
to do that?>>Scott Rogillio: We have a spreadsheet,
it’s about four tabs and it kind of, what you’re doing is try and identify from the
IT perspective what is this change going to, what does it mean to the system. Are there
interfaces that need to change so how the IT manager would use it is start filling out
everything that you think might be need to be created new, like if there’s a new page,
is there a new report, is there a new interface, is there new database tables. You start identifying everything that you
know will need to change in the system and then you kind of put your IT hat on and you
start saying okay is this a complex, is it going to take my developer you know once all
the requirements are laid out is this like a 24-hour task. Is this a 48-hour task, is
this a 72-hour task, you know 160. But for them it’s just is it very simple
or is it very complex. And they kind of put numbers next to it. I’ve got maybe reports
I put five, I’ve got five medium sized reports and it works backwards and then calculates,
you know what are the time if it’s 24 hours to do this IT work it kind of calculates backwards
to determine, well what is the technical, what is the conceptual design, what is the
change management required for this task. So as you fill out all the spreadsheet of
all the same areas that you know are going to change in your system it kind of will at
the end say it’s going to take so many developers, it’s going to be 5,000 hours of developer
time, it’s going to be 2,000 hours for a project manager and that’s how we get our
estimates. And we also can tweak it for the unknowns
if these are bills coming in from a legislative session. We can dial up the uncertainty because
we know there’s some risk there if it’s something we can really sit down with the
program team and walk through this and some of that unknowns come out and we can lower
those risk factors a little bit. But it’s basically a spreadsheet that we’ve
used for, or at least I’ve been using for a number of years now.>>Jonathan: Well Scott that sounds like a
great concept. This is Jonathan in Louisiana. Would you be willing to share a blank template
of that that we could possibly use as a starting point for our own? Because we’ve always
had an issue with estimating time for change request.>>Scott Rogillio: Sure.>>Jonathan: And we’ve had various little
tools here and there and nothing automated but if you have something that’s worked
for you would you be willing to share that? Do you have a blank one?>>Scott Rogillio: Yeah. I can create a blank
one, some of it has, one of them feeds another spreadsheet for our finance and budget but
I can clean, pull that little section out because it won’t make any sense except for
our own budget folks here.>>Jonathan: Yeah. Or you could just send,
we’ll deal with it; you know we can take it out ourselves. That’ll be easier for
you just to send one, you don’t have to, you don’t have to scrub or sanitize it you
know.>>Scott Rogillio: Okay. And who should I
send that to? Joyce is that something I can send to.>>Joyce Rose: Yes. Please.>>Scott Rogillio: You all that you could
disperse to everybody or make available?>>Elizabeth Mertinko: If you send that to
Joyce we can send that to the people, the folks that have, that are participating today.
So if you go ahead and send that to Joyce and then Joyce you can send it along to me
and we can send it out.>>Scott Rogillio: Okay.>>Joyce Rose: Okay.>>Scott Rogillio: We constantly kind of tweak
this because we’re also looking at, just because we estimate it I go back and work
with my managers to make sure that our estimates are on track because we don’t want to overestimate
or you know, be way off or under and so we’re constantly looking at with these teams is
this still, you know (Suzy Miller) who’s on the call you know sometimes we’re on
within 5% or even less. So we’re pretty confident when we adjust
everything based on the risk and the knowns and unknowns and we’re getting pretty confident
with it. So we have, there’s always, you know until you’re familiar and run all the
way through and then come back and check your estimates it’s hard to trust the system
until you’re very confident in it.>>Jonathan: Well it’s a great, it would
be a great start for us. We could tweak it some but like you said and figure out how
to use it and start to measure it then tweak it. But I mean we need the starting point
you know because we critically need that kind of tool whether it’s automated or so, no
we really appreciate that Scott. Thanks.>>Scott Rogillio: Sure. No problem.>>Joyce Rose: So Scott I just want to make
sure that there’s no licensing issues and this is actually in the public domain and
there’s no problem distributing it correct?>>Man: Sounds homegrown to me but I’ll
let Scott answer.>>Scott Rogillio: Yeah this one’s, I’ve
used it for ten years it’s as far as I know it was home grown from myself and a couple
others at a consulting company awhile back and there’s, should be nothing proprietary,
once you see like yeah there’s nothing proprietary on this.>>Joyce Rose: Okay. Now here’s another,
this has always fascinated me, Texas Scott you do your maintenance internally, the state,
you have state staff doing your maintenance?>>Scott Rogillio: Yes.>>Joyce Rose: Okay. So I’m often, and things
that always drove me crazy as the project manager in Wisconsin is how did I, how do
I know that a vendor doing maintenance is quoting me an accurate price for a change
that I submit? And I guess that’s a rhetorical question not needing an answer.>>Scott Rogillio: Well some of, we have had
times where we’ve done some staff where we have vacancies and the market’s pretty
hot, it’s hard to keep state staff especially with Java developers now where we’re brought
on maybe three or four additional contract staff that are just on an hourly rate. And they just kind of follow in line with
all our other staff and we’ve estimated this change is 60 hours or 40 hours or 10
hours and we expect them to kind of do that. When it’s on a, where we do the debits we
kind of have, we kind of have a price in mind what we’re you know using our template we
expect this to be a $500,000 effort and then we kind of wait for their replies back to
see kind of what that is and see if it’s in line with what our estimates are.>>Joyce Rose: Right. Well yes, thank you.
Thank you. Again I wasn’t exactly expecting an answer but you did provide an answer so
I’m very pleased and thank you.>>Elizabeth Mertinko: We have a few questions
via chat is that okay?>>Joyce Rose: Absolutely.>>Elizabeth Mertinko: Okay. Colleen to pull
you into the conversation we have a question, how many program areas do you guys support?>>Colleen Mousinho: We have basically all
of child welfare in our SACWIS system, is that the question? We have everything from
intake to investigation to ongoing, foster care, adoptions, payment of foster parents
and then we have the portal where we allow providers to enter information.>>Elizabeth Mertinko: Okay. And you led right
very nicely into the next question which is you mentioned the portal. Was that a challenge
to implement and if so could you talk a little bit about the challenges and how you overcame
them?>>Colleen Mousinho: I think the biggest challenge
for us was managing expectations because they were so excited to hear about the SACWIS system
but we needed to start out, and the potentials that that meant of information that they could
have access to, but we really wanted to start out small and we did. We only had limited
funding and it, you know it was more like a pilot kind of effort before we expanded
it further. So we started out with just working, giving
them access to enter contacts and the way we set it up they can only see, and this is
for private providers, they can only see the children and information about the children
that are placed with them. They want to see more, we planned to provide
more, some of the challenges are around their equipment for example, if they, one of the
things that just happened is they started to upgrade to Windows 7, IE8 or 9 if it, the
latest IE, we’re not there yet. So we would get calls to the help desk saying that they
couldn’t log on, something was wrong with [unintelligible] was down. The other change is making sure that you have
staff that can work with them, being able to add them, give them access to the system,
you know make sure that we’re giving access to the right people, making sure that they’re
trained, making sure that they’re aware of any enhancements or new features that we
add to the system. So we have to, we have some administrative overhead managing that
process.>>Elizabeth Mertinko: Great. Thank you. And
next question is for both you and for Scott. This is from Charlene in Maine asking how
difficult is it for you to plan your releases a year in advance? I know you said you’re
flexible which is great, here in Maine we plan about four months out and are continually
getting change requests to the application in addition to minor fixes so it’s very
hectic and she really likes the idea of planning things a year out. So talk to us a little bit more about how
you do that and how easy or difficult that is.>>Colleen Mousinho: It’s not easy. In a
sense one part of it’s easy for me because we’ve got SACWIS compliance issues to take
care of, so that I’ve got on the schedule. One of the things that we do as part of the,
part of the SHINES team over the year is we have made sure, I in particular and some of
my deputies, that we are included in many, many meetings, many business meetings, many
meetings with providers. So we become aware of new features or you know, new piece of
work that is coming up shortly, we get advanced notice of that work. Over time our present, now folks turn to us
and say oh yeah we can’t move forward without SHINES there. So we are getting invited to
more meetings but being there gives us the heads up that the work is coming and we were
able to put that on a schedule and start planning for it. And again of course it all gets blown out
of the water if something comes up from leadership that we weren’t aware of.>>Scott Rogillio: Here in Texas we have four
releases a year, typically there’s one November, February, May, and then August. We’ve already
set for FY ’14 the November one just because we already know some projects that need to
be released there with this being a legislative cycle we haven’t set the other ones other
than there’ll be an August into the fiscal year. But we’re just trying to wait to see if
there’s any other legislative mandates that say something needs to be in place by February
we might set a February date versus March, but typically we have four a year. And then for those changes there’s a set
time frame that they’re supposed to be working on like identifying all the CRs you know we’ll
let you now how many hours six months out are going to be available for this release
coming up. You need to have all of those requests fully
vetted with requirements by this date then we’re going to be coding in this window,
we go to test and we’re real rigid about our testing that you know prior to deployment
there’s a dead week, there’s three weeks for UAT, three weeks for system test, two
weeks for integration test that there are some hard dates in there. Now that’s being said we all always have
some CRs or change requests that kind of trickle in but there is some hard dates that we just
say it is too late in the cycle, it is too risky and it will have to go to the next release. But trying to get that schedule in place to
say here’s your milestones, get your requests in here, we got to have all the requirements
here which is sometimes the hardest getting all the requirements, it’s not so hard once
we have them to start the coding and testing but getting that, getting those requirements
finalized can sometimes be a challenge here.>>Elizabeth Mertinko: Okay. And can you both
tell us what platform and language are used in your SACWIS systems please?>>Colleen Mousinho: Java, we’re a Web,
SHINES is Web based, it’s an Oracle platform and it’s Java.>>Scott Rogillio: Same here, we’ve got
some Legacy COBOL and Tuxedo mixed in that we’re trying to have a project starting
up next year to move off of those older Legacy technologies.>>Elizabeth Mertinko: Okay. Crystal do we
have any questions on the phone?>>Coordinator: At this time there are no
other questions.>>Colleen Mousinho: Joyce can I give a plug
for something?>>Joyce Rose: You certainly may.>>Colleen Mousinho: One of the things I think
we wish we have done as far as stakeholder management, when we attended one of the ACF
regional trainings you guys introduced us to the stakeholder analysis tool.>>Joyce Rose: That is correct.>>Colleen Mousinho: And I shared it with
the business here because they’re getting ready to roll out the new safety response
system and they loved it. So I just wanted to give a plug for that, I think that’s
a very helpful tool.>>Joyce Rose: Thank you very much Colleen.
And if anyone would like that I think we could probably make that available too, correct
Elizabeth?>>Elizabeth Mertinko: Absolutely yes. If
you send that on to me I can go ahead and send that out. Just so you all know what my
plan is if you’ve registered for today’s Webinar we do have your e-mail address, which
means I can send things out to you. Those of you who registered by about noon
time today should have also gotten the slides for today’s presentation so that’s the
e-mail list that I’ll use to send things out. Joyce also gave her e-mail address at the
beginning of the presentation so you can certainly follow-up with her to receive things.>>Joyce Rose: Okay. Let’s move on to wrap
up and we will finish just about on time. So what was accomplished today? Well first
of all I want to apologize for a few little technical glitches but hopefully by the next
Webinar we’ll have those worked out. What we did today is we provided a basic review
and refresher of the initial stages of the project life cycle touching on planning, procurement,
stakeholder management as well as applying risk in change management processes to enhance
our project success. I believe that we moderated and had an excellent
discussion with our guest presenters getting a lot of tips, we got a new tool, a couple
new tools that we’re going to send out for all of our attendees and you know there was,
we did provide the forum for receiving attendee questions both in chat and also via telephone. So now what’s next? Well any follow-up regarding
any questions and of course sending out materials that were asked for. Secondly the next Webinar,
which is Part two of the Project Life Cycle will be toward the end of June. Again please watch for specifics via ListServ
and we would love to have the same type of participation and discussion at our next meeting. So again this Webinar has been recorded and
will be made available online. When it is complete and posted we will send a message
via the SACWIS managers ListServ with the link. Again, I want to extend a wonderful thank
you to our guest participants and of course to all of you who are attending and for asking
questions. And again I encourage you to submit any specific ideas for a Webinar topic to
me at my e- mail address, which is on this slide, it should only take you a quick second
to jot it down. So thank you very much and see you all in
June. Goodbye.>>Coordinator: Thank you for joining today’s
conference call. All parties may disconnect at this time.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *